Статья поделена на три части части. В первой содержится общая информация о том что такое BGP hijacking и его традиционный вариант. Для тех кто знаком с этим явлением, рекомендуется перейти сразу ко второй части. Во второй части будет описан метод анонсирования чужих префиксов с помощью добавления чужой AS в свой AS-SET. В третьей части, будет сделана оценка сложности использования метода, описанного во второй части, для захвата IP-адреса ресурса torproject.org и выписки сертификата для него. Предполагается, что читатель знаком с принципами работы BGPv4.
Если в двух словах, то BGP hijacking это захват чужих IP-адресов (случайный или преднамеренный).
Обычно, BGP hijacking выглядит таким образом: AS, которой не принадлежит какой-то префикс начинает его (чужой префикс) анонсировать, аплинки/пиры его принимают, и он начинает распространяться по Интернет. Принимают они его по той причине, что нет фильтрации префиксов на стыке (либо это ошибка конфигурации, либо так задумано (т.к. построить префикс-фильтр на стыке с очень крупными операторами очень сложно ввиду различных причин, для этой статьи это не важно)). Один из самых громких примеров недавнего времени, когда Ростелеком (AS12389) начал анонсировать префиксы Mastercard (AS26380), Visa и некоторых других финансовых организаций (по официальной версии, в результате сбоя ПО). Как выглядели эти анонсы, можно посмотреть в истории bgplay (просмотр через web, json (архив)), вот один из них на одном из коллекторов RIPE (префикс 216.119.216.0/24 принадлежит Mastercard (AS26380)):
А вот как выглядел настоящий анонс:
Т.е. в данном случае Ростелеком анонсировал префикс непосредственно от своей AS (последняя AS в AS-PATH — 12389). Проблемы можно было бы избежать, если бы аплинки и пиры Ростелекома фильтровали префиксы от Ростелеком путём построения префикс-листов по AS-SET и/или валидировали префиксы по ROA RPKI. Построение префикс-листов между крупными операторами зачастую не делается, а RPKI тоже внедрили далеко не все (но прогресс есть). Такой hijacking, теоретически, может совершить кто угодно, но только если анонсируемый префикс «просочится» через хотя бы один аплинк/пир. Обычно, крупные операторы России настраивают префикс-фильтры в сторону своих клиентов и поэтому, небольшие AS (маленькие/средние операторы, некоторые хостинги и некоторые предприятия), почти всегда, такую атаку совершить не могут (но опять же, это всё зависит от региона/страны/конкретного оператора).
Однако, злоумышленники всё-таки находят места (аплинков), где фильтрация не настроена (В 2017 году лидером по hijacking была Бразилия) и осуществляют атаку захват IP-адресов (зачастую, такие события попадают в новостные ленты), для большей эффективности атаки, могут анонсировать более специфичные префиксы (с более длинной маской), чем настоящий оригинатор. Теперь перейдём к варианту атаки, где не спасают ни валидация по ROA RPKI, ни префикс-листы, построенные по AS-SET.
Рассмотрим следующий сценарий:
В теории, это довольно сильная атака, но к счастью, на практике возникнут следующие ограничения:
Возможные меры защиты:
По факту, для большинства читателей единственный применимый для них совет это №2 (относительно использования account в CAA-записи) и частично №1 в контексте выбора хостера с хорошей связностью. При этом нужно помнить про возможные атаки на DNS-сервис, в котором вы хостите свои записи (но это отдельный вопрос и по нему имеется много материалов)
Злоумышленнику нужно решить две задачи:
Вводные:
Как видно, CAA-запись есть, можно получить сертификат у letsencrypt, к аккаунту привязки нет в CAA-записи, значит задача теоретически решаема злоумышленником. IP-адреса домена torproject.org принадлежат довольном известному хостингу Hezner.
Допустим, ЦА злоумышленника это клиенты какого-нибудь российского оператора. Hezner не является клиентом российских операторов (но имеет пиринг с крупными — напрямую или через IX-ы). Чтобы злоумышленнику перенаправить трафик ЦА к себе, проще всего, стать клиентом этого оператора и просто выиграть за счёт более высокого local-pref. Здесь особо всё относительно просто и понятно.
Чтобы получить сертификат в letsencrypt, нужно чтобы провайдер, в котором хостится letsencrypt стал направлять трафик к злоумышленнику, а не в Hezner (AS24940). letsencrypt резолвится в разные адреса для американских и европейских IP, но давайте разберёмся насколько сложно будет повлиять на то, чтобы трафик с acme-v02.api.letsencrypt.org/2.19.125.202 уходил на хост злоумышленника. Тут мы сталкиваемся с тем, что letsencrypt хостится в CDN Akamai, который имеет очень хорошую связность по всему миру (присутствует на большинстве крупных IX, имеет прямые стыки с большим количеством крупных игроков). Akamai не имеет публичного LG, в принципе для клиентов есть API с помощью которого можно делать traceroute/ping, но и без публичного LG можно взглянуть в peering db, чтобы оценить масштаб их присутствия. Аналогично можно посмотреть на hezner. Нетрудно увидеть, что у обеих AS имеется присутствие на одних и тех же IX, отсюда можно сделать вывод что с вероятностью близкой к единице, префиксы AS Hezner (AS24940) в таблице Akamai(AS20940) видны с AS_PATH 24940. Это означает, что если злоумышленник попробует проанонсировать через какой-нибудь IX префиксы Hezner-а, то они проиграют по AS_PATH настоящим анонсам от Hezner (т.к. в AS_PATH будет AS злоумышленника). Возможным решением может быть организация «прямого» пиринга между злоумышленником и Akamai (если Akamai на это согласится и если при этом будет local-pref выше, чем на стыках с IX-ами).
Если подвести итог, то путём добавления чужой AS в свой AS-SET можно вызвать значительную деградацию веб-сайта torproject.org (для большого количества клиентов, но не для всех в общем случае), но получить SSL-сертификат torproject.org в letsencrypt, скорее всего, не получится из-за хорошей связности между настоящим оригинатором (Hezner) и CDN, который используется letsencrypt (Akamai). Однако в других случаях, когда между хостингом сайта-жертвы и центром сертификации имеются транзитные AS и они присутствуют в AS_PATH, то риск получения сертификата описываемым методом значительно повышается.
Простой BGP hijacking
Если в двух словах, то BGP hijacking это захват чужих IP-адресов (случайный или преднамеренный).
Обычно, BGP hijacking выглядит таким образом: AS, которой не принадлежит какой-то префикс начинает его (чужой префикс) анонсировать, аплинки/пиры его принимают, и он начинает распространяться по Интернет. Принимают они его по той причине, что нет фильтрации префиксов на стыке (либо это ошибка конфигурации, либо так задумано (т.к. построить префикс-фильтр на стыке с очень крупными операторами очень сложно ввиду различных причин, для этой статьи это не важно)). Один из самых громких примеров недавнего времени, когда Ростелеком (AS12389) начал анонсировать префиксы Mastercard (AS26380), Visa и некоторых других финансовых организаций (по официальной версии, в результате сбоя ПО). Как выглядели эти анонсы, можно посмотреть в истории bgplay (просмотр через web, json (архив)), вот один из них на одном из коллекторов RIPE (префикс 216.119.216.0/24 принадлежит Mastercard (AS26380)):
"source_id": "05-193.203.0.185",
"path": [
6939,
12389
],
"community": [],
"target_prefix": 216.119.216.0/24А вот как выглядел настоящий анонс:
"source_id": "05-193.203.0.63",
"path": [
6720,
8447,
32787,
26380,
26380,
26380
],
"community": [
"1120:1"
],
"target_prefix": 216.119.216.0/24Т.е. в данном случае Ростелеком анонсировал префикс непосредственно от своей AS (последняя AS в AS-PATH — 12389). Проблемы можно было бы избежать, если бы аплинки и пиры Ростелекома фильтровали префиксы от Ростелеком путём построения префикс-листов по AS-SET и/или валидировали префиксы по ROA RPKI. Построение префикс-листов между крупными операторами зачастую не делается, а RPKI тоже внедрили далеко не все (но прогресс есть). Такой hijacking, теоретически, может совершить кто угодно, но только если анонсируемый префикс «просочится» через хотя бы один аплинк/пир. Обычно, крупные операторы России настраивают префикс-фильтры в сторону своих клиентов и поэтому, небольшие AS (маленькие/средние операторы, некоторые хостинги и некоторые предприятия), почти всегда, такую атаку совершить не могут (но опять же, это всё зависит от региона/страны/конкретного оператора).
Однако, злоумышленники всё-таки находят места (аплинков), где фильтрация не настроена (В 2017 году лидером по hijacking была Бразилия) и осуществляют атаку захват IP-адресов (зачастую, такие события попадают в новостные ленты), для большей эффективности атаки, могут анонсировать более специфичные префиксы (с более длинной маской), чем настоящий оригинатор. Теперь перейдём к варианту атаки, где не спасают ни валидация по ROA RPKI, ни префикс-листы, построенные по AS-SET.
BGP hijacking с добавлением AS жертвы в свой AS-SET
Рассмотрим следующий сценарий:
- Злоумышленник получает AS и IP-адреса (в самом деле, технически, IP-адреса ему не нужны, скорее они лишь для того, чтобы не вызывать вопросов).
- Злоумышленник подключается к различным крупным операторам и IX-ам (минимально — хотя бы к одному оператору или IX), указывая в качестве источника данных об анонсируемых префиксов не просто свою AS, а свой AS-SET (это нормальная практика для межоператорского взаимодействия (в том числе при в отношениях клиент-аплинк) или для включения на IX-ах)). В нормальном случае, указывается AS-SET, а не просто AS, когда подразумевается, что клиент не тупиковый, а у него у самого есть (или будут) клиенты с bgp и своими сетями.
- Злоумышленник через некоторое время добавляет AS жертвы в свой AS-SET и начинает анонсировать его префикс через себя, т.е. анонсируемый AS-PATH выглядит так: «AS_злоумышленника AS_жертвы». С точки зрения автоматически построенных префикс-листов и с точки зрения RPKI это совершенно валидный анонс, поэтому оба механизма защиты здесь не сработают.
- Проанонсированный префикс начинает конкурировать с реальным анонсом (анонсом жертвы), где-то он выиграет и попадёт в таблицу маршрутизации, где-то проиграет и не попадёт (там останется анонс жертвы). Это зависит от того как много аплинков и как много IX-ов использует злоумышленник. Когда злоумышленник подключается к какой-то AS как клиент, то внутри неё он (чаще всего) выиграет у жертвы за счёт большего local-pref (если только жертва не является клиентом того же аплинка, тогда по AS-PATH выиграет жертва, если не делает препендов), т.е. злоумышленнику нужно подключиться к максимально большому количеству аплинков своим AS-SET'ом, чтобы максимизировать эффективность своей атаки.
Также злоумышленник должен подключиться к максимальному количеству IX-ов, т.к. обычно, тупиковые AS выставляют наибольший local-pref на IX-ы и если префикс жертвы не участвует в IX, то он проиграет анонсу злоумышленника в таблицах маршрутизации тупиковых AS.
В теории, это довольно сильная атака, но к счастью, на практике возникнут следующие ограничения:
- Нужно оформлять юр.лицо, как минимум одно, а по факту, скорее всего потребуются в разных странах.
- Нужно заключать договора с операторами, IX-ами, почти всегда вносить платёж за подключение, с LIR/RIR.
- Некоторые операторы всё-таки не строят префикс-листы по AS-SET автоматически, им нужно писать письма для этого. Опытный администратор что-то заподозрит, если в AS-SET неизвестной компании вдруг появится AS-ка широко известной.
- После совершения атаки, используемое оборудование (если оно будет размещено в каком-нибудь датацентре), скорее всего будет изъято в случае открытия уголовного дела.
- Префикс-листы у разных операторов/IX обновляются в разное время, поэтому потребуется провести анализ того кто когда обновляет, это тоже не самая простая работа.
Возможные меры защиты:
- Теоретически, чтобы защититься от такой атаки, нужно иметь как можно больше стыков с операторами (лучше, клиентских, т.к. на них local-pref выше) и IX-ами. Т.е. делать тоже самое что будет делать злоумышленник. Конечно же на практике это чрезвычайно сложно реализовать и потребует значительных ресурсов. Такой способ актуален разве что для сервисов, которые занимаются предоставлением услуг информационной безопасности на профессиональной основе.
- Если у вас веб-сайт, использовать CAA-запись с заданием account (если ваш поставщик SSL-сертификата это поддерживает. letsencrypt поддерживает) (см. RFC6844). В этом случае злоумышленник не сможет выписать сертификат (если только не сможет изменить CAA-запись)
- Теоретически, повсеместное внедрение BGPsec должно устранить такую атаку, но пока что не понятна его судьба (на практике ещё не применяется или очень редко).
- Внедрение альтернативной верификации AS_PATH (без BGPsec) (пока что это драфт, который решает описываемую проблему в случае его повсеместного внедрения).
- Запрет бесконтрольного добавления чужой AS в свой AS-SET (без разрешения владельца AS) мог бы сократить возможность проведения подобных атак в тех регионах, где применяются AS-SET'ы для фильтрации на стыках. Сейчас такого запрета нет.
По факту, для большинства читателей единственный применимый для них совет это №2 (относительно использования account в CAA-записи) и частично №1 в контексте выбора хостера с хорошей связностью. При этом нужно помнить про возможные атаки на DNS-сервис, в котором вы хостите свои записи (но это отдельный вопрос и по нему имеется много материалов)
Сложно ли захватить torproject.org
Злоумышленнику нужно решить две задачи:
- Перенаправить трафик в отношении целевой аудитории (ЦА — кто будет получать фейковый сайт)
- Сгенерировать сертификат
Вводные:
$ dig torproject.org CAA +short
128 issuewild "\;"
0 iodef "mailto:torproject-admin@torproject.org"
128 issue "globalsign.com"
128 issue "letsencrypt.org"
$ dig torproject.org +short
95.216.163.36
138.201.14.197
Как видно, CAA-запись есть, можно получить сертификат у letsencrypt, к аккаунту привязки нет в CAA-записи, значит задача теоретически решаема злоумышленником. IP-адреса домена torproject.org принадлежат довольном известному хостингу Hezner.
Допустим, ЦА злоумышленника это клиенты какого-нибудь российского оператора. Hezner не является клиентом российских операторов (но имеет пиринг с крупными — напрямую или через IX-ы). Чтобы злоумышленнику перенаправить трафик ЦА к себе, проще всего, стать клиентом этого оператора и просто выиграть за счёт более высокого local-pref. Здесь особо всё относительно просто и понятно.
Чтобы получить сертификат в letsencrypt, нужно чтобы провайдер, в котором хостится letsencrypt стал направлять трафик к злоумышленнику, а не в Hezner (AS24940). letsencrypt резолвится в разные адреса для американских и европейских IP, но давайте разберёмся насколько сложно будет повлиять на то, чтобы трафик с acme-v02.api.letsencrypt.org/2.19.125.202 уходил на хост злоумышленника. Тут мы сталкиваемся с тем, что letsencrypt хостится в CDN Akamai, который имеет очень хорошую связность по всему миру (присутствует на большинстве крупных IX, имеет прямые стыки с большим количеством крупных игроков). Akamai не имеет публичного LG, в принципе для клиентов есть API с помощью которого можно делать traceroute/ping, но и без публичного LG можно взглянуть в peering db, чтобы оценить масштаб их присутствия. Аналогично можно посмотреть на hezner. Нетрудно увидеть, что у обеих AS имеется присутствие на одних и тех же IX, отсюда можно сделать вывод что с вероятностью близкой к единице, префиксы AS Hezner (AS24940) в таблице Akamai(AS20940) видны с AS_PATH 24940. Это означает, что если злоумышленник попробует проанонсировать через какой-нибудь IX префиксы Hezner-а, то они проиграют по AS_PATH настоящим анонсам от Hezner (т.к. в AS_PATH будет AS злоумышленника). Возможным решением может быть организация «прямого» пиринга между злоумышленником и Akamai (если Akamai на это согласится и если при этом будет local-pref выше, чем на стыках с IX-ами).
Если подвести итог, то путём добавления чужой AS в свой AS-SET можно вызвать значительную деградацию веб-сайта torproject.org (для большого количества клиентов, но не для всех в общем случае), но получить SSL-сертификат torproject.org в letsencrypt, скорее всего, не получится из-за хорошей связности между настоящим оригинатором (Hezner) и CDN, который используется letsencrypt (Akamai). Однако в других случаях, когда между хостингом сайта-жертвы и центром сертификации имеются транзитные AS и они присутствуют в AS_PATH, то риск получения сертификата описываемым методом значительно повышается.
