Атаки на BGP.
Данные нарушения могут быть получены в результате осуществления следующих атак на протокол BGP.
BGP работает на основе протокола TCP, прослушивая порт 179. Следовательно, протокол BGP уязвим для атак на TCP, о которых мы говорили ранее.
Атака confidentiality violations (нарушение конфиденциальности). Как уже упоминалось ранее, маршрутные данные BGP передаются в открытом текстовом виде, что позволяет легко перехватывать информацию (это происходит потому, что конфиденциальность маршрутных данных не является общим требованием).
Атака replay (воспроизведение). BGP не включает мер по предотвращению повторного использования перехваченных сообщений.
Атака message insertion (вставка сообщений). BGP не включает защиты от вставки сообщений. Однако поскольку BGP использует транспортный протокол TCP, при завершенной организации соединения вставка сообщений внешним узлом потребует точного предсказания порядковых номеров (такое предсказание возможно, но весьма затруднено для хороших реализаций TCP) или перехвата сессий.
Атака message deletion (удаление сообщений). BGP не включает защиты от удаления сообщений. Опять-таки, такие атаки весьма затруднены для качественных реализаций TCP, но исключить их полностью нельзя.
Атака message modification (изменение сообщений). BGP не включает защиты от изменения сообщений. Синтаксически корректная модификация без изменения размера данных TCP в общем случае будет незаметной.
Атака Man-in-the-middle (атаки с участием человека). BGP не включает средств защиты от MITM-атак. BGP не использует аутентификации партнеров, и такие атаки становятся «детской игрушкой».
Атака denial of service (атаки на службы). Хотя ложные маршрутные данные сами по себе могут служить DoS-атакой на конечную систему, пытающуюся передавать данные через сеть, и сеть в целом, некоторые виды ложной информации могут создавать DoS-атаки на сам протокол BGP. Например, анонсирование большого числа более специфичных маршрутов (более длинных префиксов) может привести к росту трафика BGP и размера таблиц маршрутизации, который окажется неприемлемым для системы.
Подводя итог описанному в этом разделе, следует отметить, что наличие рисков обусловлено тремя основными уязвимостями:
отсутствием встроенного механизма защиты целостности и актуальности данных, аутентификации партнеров для передачи сообщений;
отсутствием механизма проверки полномочий AS для анонсируемой информации NLRI (Network Layer Reachability Information);
отсутствием механизма обеспечения достоверности атрибутов маршрутов, анонсируемых AS.
Простой BGP hijacking.
Обычно 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, риск получения сертификата описываемым методом значительно повышается.
Петухов Олег, юрист в области международного права и защиты персональных данных, специалист в области информационной безопасности, защиты информации и персональных данных.
Телеграм-канал: https://t.me/zashchitainformacii
Группа в Телеграм: https://t.me/zashchitainformacii1
Сайт: https://legascom.ru
Электронная почта: online@legascom.ru
#защитаинформации #информационнаябезопасность
