Вернуться к старой версии портала ПЕРЕЙТИ
Оставить отзыв
  1. Статьи
Заметки пользователей
7966
2
26.04.2018 06:30
PDF
7966
2

История одного BGP hijack, или необходимо ли фильтровать full-view от аплинков

Идея написать статью о необходимости ревизии принимаемых от аплинков BGP full-view (FV) анонсов возникла еще в конце прошлого года, после обнаруженного большого количества hidden (rejeceted by import policy) маршрутов принятых после включения очередного аплинка в Казахстане. Более детальный анализ показал "богатость" as-path отфильтрованных по prefix lendth маршрутов, т. е. специфичных по длине маски чем /24. В тоже время были проанализированы еще с десяток FV от разных апстримов, а также маршруты, принимаемые с обменников (IX - Internet Exchange). По сути оказалось, что дела у остальных обстоят не намного лучше увиденного в Казахстане.

Новые проекты, решение текущих задач отодвинули эту идею на второй план, и в некоторой степени она даже подзабылась. Но произошедший вчера, 24 апреля 2018 года, случай BGP hijack с инфраструктурным значимым префиксом Amazon (для фишинговой атаки на "MyEtherWalet" (MEW)) AS10297 был "угнан" префикс принадлежащий Amazon префикс 205.251.192.0/24, к которому привязаны корневые DNS сервера Amazon. В результате DNS-запросы пользователей, которые в качестве DNS-серверов использовали DNS Amazon перенаправлялись на подменный DNS-сервер злоумышленников, где myethewallet.com резолвился в IP-адрес фишингового сайта, работающего по протоколу HTTP, т. е. без SSL, или использующего поддельные сертификаты. По сообщениям пользователей Твитер атака длилась несколько часов и злоумышленникам удалось похитить значимое количество криптовалюты благодаря скомпрометированным данных пользователей.
Сначала в Твитере появилось сообщение, что это произошло с DNS Google и выглядело очень правдоподобным на фоне наблюдаемых вчера проблем со знаменитыми 8.8.8.8 и 8.8.4.4.


Немного позже пользователи начали оставлять комментарии, что произошедшее случилось все-таки с DNS Amazon.

Оригинальный префикс Amazon имеет длину маски /23:


whois -h whois.radb.net 205.251.192.0/23 | grep descr
descr: Amazon prefix

205.251.192.0/23 *[BGP/170] 2w3d 03:59:28, MED 20, localpref 100
AS path: 3257 16509 I, validation-state: unverified


Для атаки был применен так называемый more specific prefix 205.251.192.0/24, который при маршрутизации трафика всегда выигрывает перед less specific 205.251.192.0/23. Данный вид атаки по сути является очень древним, происходит с довольно часто (раз в несколько месяцев случаются довольно громкие события, по значимости аналогичны вчерашнему), и называется BGP Hijack.

Ниже на скриншоте наглядно отображен результат произошедшего с применением аналитического сервиса RIPE BGPlay: 

 

Из данного слайда видно, что префикс был проансирован AS10297 (eNET Inc., одним из американских хостинг провайдеров) в Tier1 AS6939 (Hurricane Electric), что позволило подвергнуть атаке довольно большое количество автономных систем.

Скриншот браузера при попытке открытия фишингового сайта:

К сожалению, многие пренебрегли подобными предупреждениями.

Из начала статьи можно предположить почему подобное возможно. Ниже представлен слайд презентации из выступления на одном из недавних мероприятий в городе Алма-Ата, наглядно отображающий суть BGP Hijack и не требующий комментариев.

Подобное возможно по двум причинам:

  1. Аплинки не осуществляют фильтрацию клиентских анонсов по атрибуту origin с использованием записей из баз IRR (часто причиной тому являются "раздутые" клиентские as-sets и вендорские аппаратные ограничения по количеству строк конфигурационных файлов, но в большей степени - это безразличие, нежелание что-либо внедрять, отсутствие компетенции);
  2. Со стороны клиентов нет ревизии принимаемых маршрутов FV на предмет фильтрации не принятых к распространению маршрутов, в т.ч. специфичных чем /24.


На слайдах выше показаны отфильтрованные в FV маршруты, специфичней чем /24, а также их количество.
Отсутствие подобной фильтрации в операторских сетях позволяет злоумышленникам без каких-либо проблем сделать inject префикса жертвы.

К сожалению, каких-либо жестких ограничений на анонсы спецификов не существует.

В RFC 7454 "BGP Operations and Security", в частности, отмечается, что RIPE рекомендует не анонсировать и не принимать в Интернет для IPv4 специфичней чем /24, и для IPv6 специфичней /48.

Рекомендую в качестве import policy для аплинков применить что-то подобное и вы увидите в своих таблицах тоже hidden routes :)


>show configuration policy-options policy-statement sanity-check-Upstream
term bogons-reject {
from policy bogons;
then reject;
}
term bogons-as-reject {
from as-path grey-as;
then reject;
}
term long-prefixes-reject {
from {
route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;
}
}
​then next policy;

2 комментариев
Robot_NagNews
Robot_NagNews
Материал: Идея написать статью о необходимости ревизии принимаемых от аплинков BGP full-view (FV) анонсов возникла еще в конце прошлого года, после обнаруженного большого количества hidden (rejeceted by import policy) маршрутов принятых после включения очередного аплинка в Казахстане. Более детальный анализ показал "богатость" as-path отфильтрованных по prefix lendth маршрутов, т. е. специфичных по длине маски чем /24. Полный текст
tec1
tec1
Несколько аспектов не отраженных в статье из-за дефицита времени при ее написании. 1. Нежелательно агрегировать инфраструктурно-значимые префиксы, тем самым создавая предпосылки для BGP hijack с помощью more specific. 2. У многих существует строгое убеждение, что корневая причина зла - отсутствие какой-либо фильтрации клиентских анонсов на аплинках. Истины в подобных утверждениях немного. В основном проблема с корректной фильтрацией составная, и носит системный характер. Как уже отмечалось в статье, прежде всего, это программно-аппаратные вендорские ограничения, не позволяющие реализовать на оборудовании полноценные фильтры для довольно больших клиентских as-sets. Второй, не менее значимой составляющей проблемы, является отсутствие в правовом поле единой базы, консолидирующей все записи региональных IRR, что важно для Операторов присутствующих на рынках разных регионов. Последнему, в качестве возражения, может быть сопоставлен http://radb.net/. Но здесь, как показывает практика, есть тоже довольно серьезные проблемы с безопасностью. Еще в прошлом году обратил внимание, что кто угодно, за небольшие деньги может создать аккаунт мантейнера с дальнейшими правами создания objects. На практике это подтвердилось пару месяцев назад, когда один из наших клиентов, пользующейся сервисом Colocation, именно таким способом смог успешно проанонсировать от себя специфики префиксов China Telecom, которые успешно "ушли в мир", в т.ч. и через наших аплинков.