LIMB
Введение
Просматривая новости для форума, мне попалась заметка на китайском агрегаторе вот о чем.
В июле 2026 года абоненты китайского оператора China Mobile в провинциях Юньнань, Гуйчжоу и Сычуань столкнулись с странностью: стоило им включить Wi-Fi, как браузер сам открывал и начинал переадресовывать на специфические сайты (казино, гемблинг). Пользователи грешили на вирус, но анализ логов от lxghost показал иную картину - это была не атака на конечное устройство, а сетевая атака на уровне маршрутизации. (https://www.secrss.com/articles/93537)
Источник инцидента - автономная система AS402425, которая через аномальные BGP-объявления притянула к себе возвратный трафик, идущий из-за рубежа обратно в сеть China Mobile. Попадая в этот «перехваченный» участок пути, DNS-запросы пользователей подвергались on-path инъекции: легитимные ответы подменялись на подконтрольный диапазон 112.121.184.0/23. За период наблюдения (59 дней) было зафиксировано более 519 214 уникальных второуровневых доменов, чьё разрешение имен пострадало - от коммерческих сайтов до государственных порталов (включая правительство городского округа Тунжэнь). При этом для большинства доменов доля аномалий не превышала 2%, что указывает на методичную «низкоинтенсивную отраву» с ротацией префиксов и регионов.
Эта история - не единственный случай. Но она наглядно демонстрирует, как BGP-хайджек и последующая DNS-инъекция позволяют стоять «посреди дороги» и менять указатели, по которым идут пользователи, не взламывая ни сами сервисы, ни их криптографию.
Любопытно стало то, мне не попадались статьи на форумах об атаках на BGP.
Более того, не нужно быть большим специалистом по сетям, чтобы сообразить, что трафик, который проходит через твои серверы - золотая жила.
Поскольку банки себя защищают как правило очень хорошо (сертификаты, шифрование, проверки соединений) есть смысл посмотреть в сторону крипты.
Действительно. Криптосервисы, кошельки, DeFi-протоколы оказываются особенно уязвимы перед такой атакой. Если считать, что все содеянное ограничилось только показом рекламы, то случайный трафик плохо монетезируется, и доход должен быть около 0. Так как "автономная система" была зарегистрирована легально. А это расходы (дроп, серверы, документы, регистрация фирмы в Сингапуре и тп).
Но тогда что втихую мог сделать автор атаки (скорее всего 1-2 человека), на чем еще собирался заработать?
Об этом - дальше.
Часть 1. Анатомия доверия: уязвимости старого протокола BGP
1.1 BGP за 5 минут: AS, префиксы и отсутствие аутентификации
BGP — протокол внешней маршрутизации (eBGP/iBGP), который с 1989 года связывает автономные системы (AS). Каждая AS имеет уникальный номер (ASN) и анонсирует префиксы— блоки IP-адресов в нотации CIDR, например 111.45.0.0/17. Единица маршрутной информации в BGP - именно префикс, а не отдельный IP.
Вместе с префиксом передаётся AS_PATH список ASN, через которые прошёл анонс. Важный момент: AS_PATH не вычисляется из топологии. Он накапливается по мере распространения анонса. AS-владелец префикса формирует анонс с AS_PATH, равным её собственному номеру. Каждый следующий AS, передавая анонс соседу, добавляет свой номер в начало. В нормальной ситуации этот след совпадает с реальным маршрутом трафика, потому что анонсы идут по настроенным BGP-сессиям поверх физических линков. Но это совпадение, а не гарантия - протокол не проверяет, что AS_PATH физически возможен.
===================
AS_PATH выполняет две функции: защита от петель (если AS видит в списке свой номер - маршрут отбрасывается) и выбор пути. Алгоритм BGP Best Path Selection сравнивает маршруты по строго упорядоченному списку критериев, и одним из первых идёт длина AS_PATH: чем короче, тем при прочих равных предпочтительнее. Именно этот критерий и эксплуатируется при угоне.
Ключевой архитектурный недостаток: BGP не аутентифицирует источник анонса. В TCP-сессии между BGP-пирами нет механизма, подтверждающего, что AS56040 действительно владеет префиксом 111.45.0.0/17. Доверяем на основе политик (local preference, MED, AS_PATH length), но криптографической связи «владелец → анонс» нет. Это работало, пока интернет был иерархическим и закрытым, но в эпоху BGP hijacking становится фатальным.
1.2 Path manipulation и почему RPKI говорит «Valid»
Resource Public Key Infrastructure (RPKI) (также известна как Resource Certification) — специализированная инфраструктура открытых ключей (PKI), разработанная для обеспечения безопасности маршрутизации в интернете. Цель — связать информацию о ресурсах интернет-адресов (например, номерах автономных систем и IP-адресах) с якорем доверия.
Возвращаемся к кейсу China Mobile (июль 2026).
Атакующий AS402425 (QOREXA LABS LLC, Сингапур) не анонсировал чужие префиксы от своего имени. Он применил манипуляцию AS_PATH (path manipulation): вставил свою AS в середину пути к легитимным префиксам China Mobile, сохранив origin AS без изменений.
Как это выглядело.
Легитимный префикс 120.197.0.0/16 принадлежит Guangdong Mobile (AS56040, CMNET-GuangDong-AP). В нормальной ситуации внешние AS видят его с AS_PATH, где AS56040 - origin. Атакующий через подконтрольную AS402425 начал объявлять себя транзитом для AS56040, то есть рассылать анонсы, в которых AS_PATH содержал AS402425 как промежуточное звено. Origin оставался AS56040. Префикс оставался 120.197.0.0/16. Менялся только путь.
Почему RPKI не сработал? и это ключевой момент.
RPKI/ROV проверяет две вещи: совпадает ли origin ASN с записью в ROA, и не превышает ли длина префикса maxLength, указанный в ROA. Всё.
В кейсе China Mobile: Префикс: 120.197.0.0/16 — совпадает с ROA. Origin: AS56040 — совпадает с ROA.
Вердикт ROV: Valid.
RPKI честно говорит «всё хорошо», потому что с точки зрения того, что она умеет проверять, всё действительно хорошо. Она слепа к AS_PATH. Она не видит, что между AS56040 и остальным интернетом вставилась AS402425. Она проверяет только «кто владелец» и «та ли это маска», а не «через кого идёт трафик».
Не удалось прогрузить медиа
Именно поэтому path manipulation обходит RPKI по определению, а не из-за плохого внедрения. Это архитектурное ограничение: RPKI создавалась для проверки origin, а не пути. Sub-prefix hijack (анонс более специфичного префикса от своего имени) RPKI бы поймала — там origin меняется, и ROA бы вернул Invalid(если есть покрывающий ROA с другим origin) или Unknown(если ROA для префикса нет вообще). Это разные ситуации с разным исходом, смешивать их нельзя. Здесь же origin не менялся.
Отдельный нюанс - почему часть AS переключилась на ложный маршрут, а часть нет.
Помимо длины AS_PATH, в алгоритме Best Path Selection local preference идёт раньше длины AS_PATH. AS402425 была подключена к Cogent (AS174), а Cogent для клиентских маршрутов обычно выставляет повышенный local preference. Это означает, что для некоторых сетей решающим оказался не более короткий AS_PATH, а именно local preference - атакующий выиграл на шаге, который идёт до сравнения длин пути.
Другой фактор - тройной prependсо стороны China Mobile International (CMI, AS58453).
Для префикса 111.45.0.0/17 (origin AS56040) легитимный путь выглядел как 174 → 1299 → 58453 ×3 → 9808 → 56040 — то есть семь хопов.
AS402425 предлагала путь из трёх хопов. Тройной prepend, который должен был защитить маршрут от перехвата, превратился в приманку: он искусственно удлинил легитимный путь, сделав короткий путь через AS402425 ещё более предпочтительным для алгоритма выбора.
Не удалось прогрузить медиа
Масштаб.
Атака длилась 59 дней(июль–август 2026). За это время было зафиксировано 519 214 вторичных доменовс аномальными DNS-ответами, включая gov.cn
CDN, OCSP/CRL, авто-обнаружение и антиспам. Признак «тихого» загрязнения: низкий процент (<2%) отравленных ответов на каждый домен, ротация по префиксам, регионам и часам. Это не громкий сбой, а долгоживущее отравление «на выживание».
Итог по разделу:атака на China Mobile - это path manipulation плюс on-path DNS injection. Origin не подделывался, префикс не подделывался, поэтому RPKI возвращал Valid и не мог ничего сделать. Подмена происходила на уровне пути и на уровне DNS-ответа, которые RPKI не проверяет.
Где косяк?
RPKI проверяет origin - и там, где её включили, она работает (как показал инцидент с Rostelecom 2020, где 78% захваченных префиксов имели ROA, и там, где ROV был активен, утечка остановилась). Но для проверки пути нужна ASPA (Autonomous System Provider Authorization, RFC 9310), которая должна подтверждать, что AS_PATH соответствует реальной иерархии провайдеров. ASPA до сих пор не включена глобально и именно поэтому path manipulation остаётся «дырой по дизайну».
Мораль: старый протокол BGP слишком доверчив. И несмотря на наличие слоев (условий) дополнительных проверок все равно эксплуатируется в темную. Подводит принцип паутины: связь между защищенными AS и более безалаберными (AS может принадлежать университету, коммерческой структуре с большими потоками данных, да и вот - свежесозданной организации).
1.3 Почему интернет не фиксит это 30 лет
Здесь я стала терзать ботов. Как же так. Любой хрен с горы может с левой компании, или легальных серверов, получив доступ к анонсам маршрутизатора сломать (заддосить или перенаправить) трафик миллионам людей. Странно в наше время, правда?
Но это факт.
Мне объяснили самые умные ИИ, что тому есть три структурные причины:
1. Operational fear (страх разрыва).
Инженеры боятся фильтровать inbound-трафик из-за риска false positive. Один неправильный prefix-list на границе с транзитным провайдером — и вы теряете связность с частью интернета. Это общее соображение в сетевой инженерии: жёсткие фильтры на границе требуют идеальной актуальности данных о легитимных маршрутах, чего на практике почти никогда нет.
2. Статистика MANRS 2026
MANRS (Mutually Agreed Norms for Routing Security) — инициатива, продвигающая лучшие практики. Отчёт за 2026 год даёт картину: Filtering — 99%, Anti-spoofing — 89%, а слабое место — RPKI: 52% Ready, 41,5% Lagging. В глобальной таблице маршрутов Valid — 70,2%, Unknown — 29,5%, Invalid — 0,3%. То есть дело не в том, что «никто не фильтрует», а в том, что фильтруют по старым правилам, а криптографическую проверку не включили. И почти треть мировой таблицы (29,5%) не проверяется никак.Не удалось прогрузить медиа
Обратите внимание - почти 40 % маршрутизации идет на доверии -что приняли, тому и поверили: например, в то, что ваш AS даст более короткий маршрут к нужному ip, хотя это совсем не так.
Думаете эти 40% - никому не нужный отстой? А вот и нет! см. последний параграф (Часть 5)
3. Экономика безопасности
Внедрение RPKI/ROV требует создания и поддержания ROA в RIR (процессный overhead), настройки валидаторов на роутерах (Cisco IOS XR, Junos, BIRD и т.д.), обучения персонала и постоянного мониторинга изменений в ROA. ASPA требует ещё большего - согласования иерархии провайдеров на уровне всей индустрии. Для многих компаний угроза кажется теоретической, пока нет прямого финансового удара. ROI отрицательный с точки зрения бизнеса, пока атака бьёт не по вам.Вывод:интернет держится на полумерах. BGP остаётся протоколом доверия на слово. RPKI работает там, где её включили, и молчит там, где не включили. ASPA ждёт своего часа. И пока path manipulation обходит всё, что у нас есть, «дорога» остаётся ядовитой.
ЧАСТЬ 2. Что даёт BGP-уязвимость и сколько на этом можно поднять
Уязвимость одна: BGP не проверяет, имеет ли AS право анонсировать префикс. Всё остальное это развилки, которые атакующий проходит, когда решает, что с этой уязвимостью делать. Не «типы атак», а дерево решений с ценником на каждой ветке.Шаг 1. Притянуть трафик
Первый вопрос: как заставить чужие сети слать трафик через тебя. Вариантов три, и они различаются по цене, риску и заметности.
Sub-prefix hijack - объявить более специфичный префикс (/24 внутри чужого /16). Дёшево, быстро, работает через longest-prefix match. Но заметно: RPKI может пометить как Invalid (если ROA покрывает диапазон), и любой мониторинг это увидит.
Origin hijack - объявить тот же префикс от своего имени. Тоже дёшево, но ещё заметнее: origin меняется, RPKI часто даёт Invalid, вопросов больше.
Path manipulation - сохранить origin, вставить себя в AS_PATH. Дороже: нужен свой upstream, который согласится выставлять тебя как транзит. Тише: origin не меняется, RPKI возвращает Valid, потому что проверяет только владельца, а не путь. Именно этот вариант использовали в кейсе China Mobile.
Выбор здесь - не про «какой тип атаки», а про баланс между дешевизной и незаметностью. Sub-prefix быстрее, path manipulation тише.
Шаг 2. Решить, что делать с трафиком
Трафик притянут. Дальше — развилка.
Дропнуть (blackhole). Дёшево, не требует ничего, кроме анонса. Даёт только недоступность. Монетизация: манипуляции на рынке - каскад ликвидаций, паника, арбитраж, пока API биржи «лежит». Или просто вредительство, если цель не деньги.
Форвардить (interception). Дороже: нужно проксировать трафик к реальной цели, сохраняя сессии. Зато даёт on-path позицию - а это ключ ко всему остальному.
Шаг 3. Если форвардишь — что с этого взять
On-path позиция - это не результат, это инструмент. Что с ним делать:
Подменить DNS. Дёшево, если DNS идёт в открытом виде. Даёт перенаправление на любой сервер. А если ты контролируешь трафик, ты можешь пройти ACME HTTP-01 и получить валидный TLS-сертификат на домен жертвы - при условии, что CA и его multi-perspective validation это допустят. Тогда пользователь видит правильный домен и «зелёный замочек», но попадает к тебе. Это открывает фишинг и supply chain.
Подменить контент напрямую. Работает только там, где нет целостности: неподписанные JS, HTTP-сегменты, сайты без HSTS. Для HTTPS с валидным сертификатом — не работает без активного MITM.
Заблокировать OCSP/CRL. Не «подделать ответ» — OCSP-ответ подписан, его без ключа не сгенерировать. А именно заблокировать, рассчитывая на soft-fail у клиента. Или на то, что Chrome и Firefox давно не делают онлайн-проверку. Это скрывает отзыв уже полученного сертификата, но не создаёт новый.
Изолировать ноду. Перехватить трафик между нодой и её пирами. Работает для P2P, но требует масштаба — иначе пиры распределены и изолировать одну ноду не выйдет. И это не обязательно BGP: eclipse бывает и через Sybil, и через bootstrapping.
Шаг 4. Посчитать, стоит ли
А теперь — арифметика, которая объясняет, почему казино-редирект за $10k — это не бизнес.
Входной билет:
- Регистрация AS через RIR: ˆ1,800–2,000 в год.
- Юридическое лицо (дроп-компания): $1,000–5,000.
- Upstream-транзит: $500–2,000 в месяц.
- Префиксы, серверы, DNS-инфраструктура: ещё $1,000–2,000 в месяц.
Итого: $15,000–25,000 только за два месяца работы. Это не окупается рекламой казино. Значит, казино — не цель, а побочный продукт и камуфляж. Инфраструктура строится для чего-то, что стоит дороже.
Что стоит дороже:
- Supply chain — подмена обновлений, массовая компрометация.
- Фишинг с валидным сертификатом — кража транзакций, ключей, доступов.
- Аренда доступа — продажа on-path позиции другим группам.
- Подготовка к целевой атаке — обкатка на «безобидных» целях.
Одна уязвимость. Два режима работы с трафиком. Четыре способа монетизации. И ценник, который объясняет, почему мы видим только верхушку.
Не «пять типов атак», а один вопрос: что ты поимеешь за свои деньги и риск.
Часть 3. BGP и атаки на криптосервисы
Сценарий 1: атака на ноды
Большинство пользователей не запускают свои ноды. Кошелёк или его программный клиент обращается к внешней инфраструктуре - собственной, корпоративной или стороннего провайдера вроде Infura, Alchemy или QuickNode. Аппаратный Ledger при этом самв сеть не ходит: он получает от хоста данные для отображения и подписания.
Здесь важно сразу развести три разные цели, потомучто они живут на разных доменах, наразных IP и дают атакующему разные возможности.
- RPC-эндпоинт (mainnet.infura.io) - отдаёт состояние сети: балансы, результаты eth_call, газ, nonce, принимает подписанные транзакции.
- Фронтенд и CDN (app.uniswap.org, скрипты с CDN) - формирует то, что уйдёт на подпись.
QuoteAPI агрегатора(1inch, 0x) - отдаёт маршрут свопа и частоготовый calldata.
Перехватив только RPC, подменить calldata нельзя - его строит фронтенд. Это разные префиксы, и путатьих не стоит
Атакующий через BGP притягивает трафик к IP-адресам конкретного RPC-провайдера. Важная оговорка: сам посебе hijack не означает перехват содержимого. Если атакующий просто дропает пакеты - это blackholing, а не MITM. Для позиции на пути нужно, чтобы он трафик форвардил - это route interception.
И даже тогда: еслисоединение с RPC идёт по HTTPS, BGP-перехват сам по себе не даёт менять JSON-RPC на лету.Чтобы модифицировать содержимое, нужен один из трёх путей:
- interception + валидный TLS — через BGP+DCV или компрометацию CA;
- пользователь игнорирует TLS-ошибку — как в MEW 2018;
- RPC идёт по HTTP или клиент не проверяет сертификат — редко, но встречается в SDK и внутренних сетях.
Если атакующий решил проблему TLS, что он получает от самого RPC:
- ложные балансы и allowance — пользователь думает, что approve уже есть, или наоборот;
- ложные результаты eth_call и симуляции — интерфейс показывает «вы получите 9 980 USDC», а реально будет другое;
- подмена ответов контрактов-читалок — цена, курс, состояние пула;
- манипуляция gasPrice и gasLimit — транзакция гарантированно зависнет, пока атакующий работает;
- цензура и задержка — транзакция не уходит или уходит позже;
- ранний доступ к подписанной транзакции.
Это и есть главный аргумент всей писанины: пользователь видит ложную реальность перед подписью.
Прямое изменение to,value или data требует компрометации другогокомпонента - того, который формируетcalldata. Это может быть:
- подмена фронтенда или JavaScript-зависимости с CDN - класс KLAYswap и Celer: грузится не бинарник, а скрипт, и SRI с CSP есть далеко не везде;
- компрометация агрегатора или quote-сервиса - подсовывается «правильный UI, но другой контракт или recipient»;
- уязвимый или вредоносный wallet connector.
Здесь не нужна код-подпись- её и нет, JS грузится без неё. Именно по этому этот вектор даёт подмену calldata, recipient и адреса контракта, а перехват RPC нет.
Это не ломает Ledger и неизвлекает из него ключ. Атакующий пытается обмануть пользователя или интерфейс до момента подписи, чтобы устройство криптографически подтвердилоне то намерение, которое пользователь считает своим.
С Ledger есть нюанс. Простой перевод - адрес и сумма видны на экране,подмену заметить легче. Сложный DeFi -approve, permit, нестандартный calldata- поддержка clear signing зависит от приложения, сети,типа операции и интеграции. Если кошелёк показывает только hex или неполно декодирует calldata, это фактически blindsigning. Пользователь честно вводит пин-код,честно нажимает кнопку на физическомустройстве, но подписывает не то, чтодумает.
Secure Element работает идеально. Проблема в том, что именно ему дали подписать.
Если атакующий и есть RPC, он может увидеть подписанную транзакцию раньше значительной части сети - приусловии, что транзакция действительнопроходит через контролируемый RPC и отправляется в публичный мемпул. Некоторые RPC сразу рассылают её нескольким провайдерам или напрямую билдеру черезprivate order flow - тогда окно меньше или его нет.
Что атакующий может сделать с этим доступом:
- sandwich или front-run своей транзакцией через более быстрый канал или с большей комиссией;
- дропать или задерживать транзакцию жертвы, увеличивая своё окно для MEV.
Отправить «такую же» транзакцию он не может - для этого нужна подпись пользователя. Но встречная транзакция возможна, и её прибыль извлекается из разницы, которую создаёт транзакция жертвы.
Убыток пользователя превращается в прибыль атакующего, если стратегия успешно исполнилась. В других случаях ущерб может ограничиться комиссией, задержкой или неисполнением операции - если проскальзывание ограничено, а транзакция просто реверсится.
Sandwich работает преждевсего для публичных swap-транзакций спредсказуемым воздействием на AMM. Для приватного order flow или операций безрыночного эффекта этот сценарий не подходит.
Перехват RPC даёт ложную картину мира перед подписью. Перехват фронтенда и quote API даёт подмену самого calldata. Оба пути ведут к одной цели:устройство подписывает то, что пользовательне имел в виду. Аппаратная подпись приэтом остаётся криптографически корректной- и именно поэтому её так трудно заметить.
Сценарий2: Отравление обновления (Supply Chain Attack)
Классика, которая бьет по массовому пользователю. Криптобиржи (Binance, Bybit) и кошельки(Electrum, Exodus, Ledger Live) регулярно обновляютсвои десктопные приложения.
Механика:
- Злоумышленник анонсирует более специфичный маршрутк CDN или серверу обновлений целевого сервиса.
- Пользователь нажимает «Проверить обновления».
Поскольку загрузка часто идет по HTTP (или HTTPS сослабленной проверкой сертификатов настарых клиентах), подмена проходит незаметно.
Масштаб.
Один удачный BGP-анонс может заразить десятки тысяч пользователей за пару часов,
пока провайдер не разорвал сессию.Это не точечный фишинг, это "работа по площадям".
пока провайдер не разорвал сессию.Это не точечный фишинг, это "работа по площадям".
Сценарий3: «Черная дыра» во время волатильности (саботаж\диверсия на крипторынке).
Этоуже уровень финансового терроризма, и он не требует кражи денег напрямую.Механика:
- На рынке начинается резкий обвал (или памп). Все бегут продавать (или покупать).
- Злоумышленник (или конкурент, или манипулятор рынка) анонсирует BGP-маршрут в «никуда» (blackhole) для основных API-эндпоинтов крупной биржи.
- Миллионы пользователей видят ошибку «NetworkError», «502 Bad Gateway» или«Maintenance».Они немогут вывести средства или закрыть позицию.
- Пока пользователи паникуют и не могут двигать рынок своими ордерами, злоумышленник,у которого есть доступ к другим, незатронутым пулам ликвидности,зарабатывает на искусственно созданном дисбалансе.
Апрель 2018 года, атака на MyEtherWallet (MEW) и Amazon Route53.
Хакерыне взломали серверы MEW. Они провелиBGP-хайджек трафика, идущего к серверамDNS Amazon Route 53 (через подставную компаниюв Египте). Они подменили DNS-записи для myetherwallet.com, перенаправив пользователейна фишинговый сайт, который украл сид-фразы.
Ущерб:Десятки миллионов долларов за несколько часов.
Вывод: Если это сработало в 2018-м, то в 2026-м, с ростом сложности DeFi и RPC-зависимости, это сработает еще изящнее.
Часть 4. Почему интернет не горит синим пламенем
Экономика риска: атаковать можно многим, но выгодно — не всемBGP-атака выглядит пугающе именно потому, что она «уровнем ниже» привычной безопасности. Но у неё есть приземлённый ограничитель: это не бесплатная кнопка.
Нужна хотя бы минимальная инфраструктура - своя автономная система или доступ к чужой, BGP-сессия с апстримом, транзит или пиринг, инженерные навыки и готовность оставить след в публичных данных маршрутизации. Даже если входной билет сегодня дешевле, чем десять лет назад, он всё равно означает: атакующий действует не из браузера, а из сети, которую можно наблюдать, коррелировать и давить через провайдеров.
Отсюда и естественная селекция целей. Похулиганить можно дешевле - фишинг, малварь. BGP имеет смысл, когда ставка высокая: региональный трафик к бирже во время волатильности, инфраструктура популярного кошелька или провайдера, цепочка поставок через CDN. Поэтому мы и не видим ежедневного массового хаоса: атака требует мотивации, окна по времени и понятного способа монетизации.
Цена следов: BGP плохо совместим с анонимностью
Экономика риска объясняет, почему BGP-атака не бесплатна. Но есть второй ограничитель, который часто упускают: маршрутная атака плохо совместима с анонимностью. Там, где фишинг или малварь можно спрятать за ботнетом, BGP требует инфраструктуры, которая по дизайну публична и привязана к договорам.
Путей три, и каждый оставляет след.
1) Своя AS.
Регистрация в RIR, взносы, контракт с апстримом, кросс в датацентре, контакты NOC, платёжные следы. Даже если ASN оформлен на дроп-фирму, остаются точки давления: апстрим, IX, провайдер стойки, комплаенс, санкционные риски. Анонсы видны в RIPE RIS, RouteViews, BGPStream - это не лог на одном сервере, а аномалия, которую видно глобально и можно раскрутить назад.
2) Взлом существующей AS.
Тише, но требует уязвимости, доступа к оборудованию или инсайдера. След ведёт внутрь доверенной сети - и это одновременно преимущество и риск: расследование упирается в чужой периметр, но и сам атакующий оказывается внутри чужой инфраструктуры, которая логирует, мониторит и может привлекать спецслужбы
3) Инсайдер.
Самый опасный - и самый дорогой. Найти человека, завербовать, удержать, не спалиться. Инсайдер даёт правдоподобные следы и слабые санкционные рычаги, но требует времени, денег и работы с людьми. Это не масштабируется как бизнес-модель и именно поэтому остаётся инструментом точечных операций, а не потоковой атаки.
Вот почему массового BGP-хаоса и нет. Атакующий вынужден строить инфраструктуру, которую видно всем. Защитнику достаточно не тупить. Для разовой акции это оправдано. Для потока - нет.
Фактор времени: детект - минуты, реакция - часы (и иногда недели)
Современный интернет неплохо научился замечать аномалии. RIPE RIS, BGPStream, Cloudflare Radar, коммерческие BGP-алерты - всё это действительно способно подсветить подозрительный анонс за несколько минут. Проблема в другом: заметить не значит остановить.
Остановка почти всегда упирается в людей и организацию: кому пришёл алерт, кто дежурит, есть ли процедура эскалации, способен ли NOC быстро связаться с апстримом, а апстрим — принять решение и применить фильтр. И вот здесь появляется асимметрия, на которой паразитируют атаки:
- атакующему достаточно быть неправильным недолго,
- защитнику нужно быть быстрым, уверенным и иметь полномочия, чтобы не отрезать легитимный трафик.
В результате окно атаки определяется не тем, как быстро её видят мониторы, а тем, как долго владелец префикса и его провайдеры молчат или сомневаются. Для кражи, подмены фронтенда или MEV-манипуляций часто достаточно не дней - хватает часов, а иногда и десятков минут в самый удачный момент.
Ограничение прозрачности: BGP не читает HTTPS, но дорога всё равно даёт власть
BGP - это про маршруты L3, ему неинтересно, какой домен внутри HTTPS и что вы отправляете в POST-запросе. Даже атакующий, который стал on-path (interception), не получает рентген шифрования автоматически.
Что он видит почти всегда: IP-адреса, порты, объёмы, тайминги, иногда - свойства TLS-рукопожатия. Часто можно увидеть и SNI в TLS ClientHello, если не используется ECH (Encrypted ClientHello).
Но ключевое: контент HTTPS остаётся недоступен, пока атакующий не сделает активный MITM - то есть не заставит клиента принять не тот сертификат.
Через выпуск валидного сертификата при DCV-атаках, компрометацию CA или DNS, ошибку клиента или игнорирование предупреждения пользователем.
Из-за этого BGP-перехват - не универсальное «всё украду», а скорее точечное оружие:
- где-то он даёт только недоступность (blackhole),
- где-то - ранний доступ к подписанным транзакциям и задержки (MEV-окно),
- где-то - возможность подменить то, что пользователь увидит до подписи (фронтенд, quote API, RPC-ответы),
Системный аргумент: почему криптосервисы сами не закрывают "дорогу"?
Самый неприятный вывод - не про борьбу с атаками, а про стимулы. Большинство криптосервисов технически могли бы усилить защиту маршрутизации и имени: RPKI (ROA + ROV), грамотные фильтры у апстримов, multi-homing, anycast, собственный мониторинг BGP, DNSSEC там, где он уместен, жёсткие политики TLS (HSTS preload), CT-мониторинг, pinning в мобильных клиентах, изоляция критичных эндпоинтов.
Почему это не становится нормой по умолчанию? По тем же причинам, по которым интернет не чинит BGP уже десятилетиями.
Страх сломать легитимное.
Жёсткий ROV и фильтрация, дисциплина IRR и RPKI требуют аккуратности. Ошибка в конфигурации - и ты сам себе устроил outage. В бизнесе это ощущается как более реальный риск, чем редкая атака.
Инерция и распределённая ответственность.
Биржа не владеет дорогой до пользователя. RPC-провайдер не контролирует апстримы всех клиентов. В итоге каждый может сказать: «это проблема провайдеров», а провайдеры отвечают: «это проблема контент-платформ и их требований».
Нет мгновенной выгоды.
Защита маршрутизации - инфраструктурная гигиена. Она почти не добавляет фич продукту и плохо конвертируется в рост. Её вспоминают после инцидента - как пожарную безопасность.
И это замыкает круг. Криптоиндустрия инвестирует в математическую часть - ключи, подписи, формальную верификацию, HSM. Но слой доверия до математики - путь к нужному IP и правильному имени - остаётся коллективной зоной ответственности, где всё работает, пока работает. Поэтому интернет не горит постоянно: атака не всегда дешёвая и не всегда даёт MITM. Но когда совпадают цель, время и слабые места в дороге, криптография защищает подпись - и одновременно делает атаку окончательной, потому что пользователь подписывает то, что ему показали по скомпрометированному маршруту.
Продолжение следует...
👍55
🔥12
🤔12
😢12