[Перевод] Незваные гости — уязвимости в RPKI RP
BGP (Border Gateway Protocol, протокол граничного шлюза) — это протокол динамической маршрутизации, используемый маршрутизаторами для обмена информацией о достижимости префиксов в их сетях. BGP-маршрутизаторы могут анонсировать любые префиксы, включая и те, которыми их сети законно не владеют. Когда сети принимают такие фальшивые BGP-анонсы, вместо легитимного целевого префикса они направляют трафик в сеть злоумышленника.
Перехват префиксов (prefix hijacking) — распространенное явление в BGP-маршрутизации, случающееся как и по ошибке, так и в результате преднамеренных атак злоумышленников. Перехват может совершаться, например, с целью распространения вредоносного кода, кражи криптовалюты, отравления кэша серверов системы доменных имен (DNS) или обмана центра сертификации с целью выпуска фальшивых сертификатов. За последние 10 лет перехваты префиксов стали более изощренными и целенаправленными. Перехваты, вызванные как ошибочной конфигурацией, так и злонамеренными атаками, могут иметь катастрофические последствия для пользователей и сервисов в интернете. Для предотвращения перехватов IETF разработала и стандартизировала RPKI (Resource Public Key Infrastructure, инфраструктуру открытых ключей ресурсов).
RPKI предотвращает перехваты
RPKI проверяет подлинность префиксов BGP, позволяя сетям фильтровать фальшивые анонсы и, следовательно, предотвращать перехваты. Публичные репозитории RPKI, основанные на пяти региональных интернет-регистраторах (AFRINIC, APNIC, ARIN, LACNIC, RIPE), распространяют информацию о владельцах префиксов с помощью объектов с цифровой подписью, называемых ROA, которые связывают сетевые префиксы с ASN их владельца. Для получения этих ROA из публичных репозиториев RPKI и их проверки сети используют специальное программное обеспечение проверяющей стороны (Relying Party, RP). Таким образом, RP выступают в качестве промежуточного звена между хранилищами RPKI и маршрутизаторами, минимизируя нагрузку на маршрутизаторы, которым необходимо лишь время от времени извлекать подтвержденный RPKI материал из кэша RP, чтобы использовать его для принятия решений о маршрутизации.
За последние пять лет развертывание RPKI приобрело серьезные масштабы. Сейчас RPKI охватывает почти 50% всех интернет-префиксов (по сравнению с 6.5% в 2017 году). Многие крупные провайдеры и операторы уже используют ROA. Например, Amazon Web Services выпустила ROA для своих префиксов после взлома AWS Route 53 в 2018 году. Проверку происхождения маршрута (Route Origin Validation, ROV) применяют около 37.8% автономных систем (Autonomous Systems, AS) в интернете (по сравнению с 600 AS в 2017 году), включая таких крупных интернет-провайдеров (Internet Service Providers, ISP) и операторов, как Level 3, Cogent, Deutsche Telekom и Zayo.
Влияние RPKI на маршрутизацию в интернете уже стало заметным. Когда в 2008 году YouTube был взломан на глобальном уровне, он был недоступен в интернете по всему миру. В отличие от этого инцидента, когда в марте 2022 года были перехвачены префиксы Twitter, вместо того чтобы трафик Twitter был нарушен по всему миру, эффект от взлома был ощутим только в отдельных частях интернета, поскольку Twitter к тому моменту уже успел внедрить RPKI. Перехваченные префиксы были покрыты валидными ROA, поэтому все AS, поддерживающие проверку RPKI, отбрасывали фальшивые анонсы, и их клиенты оставались незатронутыми.
С другой стороны, с ростом числа пользователей любая несогласованность, уязвимость или неправильная конфигурация в RPKI будет оказывать все большее влияние на стабильность интернета, поскольку все большее число сетей может быть этим затронуто. Потенциальный ущерб может иметь значительные последствия для экономики и общества, поскольку почти все, что мы делаем, теперь зависит от корректной работы интернета.
В 2023 году мы провели обширный анализ безопасности всех популярных реализаций RP, представленных на рынке. Мы обнаружили серьезные уязвимости и продемонстрировали, как злоумышленники в сети могут использовать их для целого ряда атак, включая отказ в обслуживании (Denial-of-Service, DoS), отравление кэша (Cache Poisoning) и обход каталога (Path Traversal). Мы также выявили несоответствия в поддержке рекомендаций стандарта RFC в разных реализациях. Все эти проблемы напрямую влияют на целостность и корректность данных, на которые опираются маршрутизаторы.
Почему устранять неполадки c RP сложно
Несмотря на его центральную роль в инфраструктуре RPKI, до нашего исследования не было проведено ни одной комплексной оценки программного обеспечения RP. Если брать во внимание внутреннее устройство RP, то это неудивительно. Реализации RP сложны, поскольку поддерживают широкий спектр функциональных возможностей, необходимых для взаимодействия с RPKI-репозиториями и проверки криптографических материалов RPKI. Такая сложность делает практически невозможным использование традиционных инструментов анализа уязвимостей, таких как фаззеры.
Устранение препятствий на пути к фаззингу RP
Чтобы устранить существующий пробел в анализе уязвимостей RP, наша команда в Национальном Исследовательском Центре Прикладной Кибербезопасности ATHENE разработала новый инструмент для фаззинга, который мы назвали CURE. CURE соединяет в себе функциональность фаззера (создание мутированных объектов, выполнение целевого ПО, анализ результатов) с функциональностью RPKI по созданию, подписанию и сопряжению RPKI-объектов. С помощью CURE мы реализовали собственную оптимизированную версию полнофункционального RPKI-репозитория, которая позволяет нам создавать валидные структуры RPKI-репозитория на основе RPKI-объектов, которые мы хотим протестировать во взаимодействии с RP.
Серьезные уязвимости и несоответствия в разных реализациях RP
В ходе нашего исследования мы обнаружили 18 серьезных уязвимостей. Было внесено пять записей в CVE, одна из которых получила рейтинг critical с оценкой 9.3. Уязвимости затрагивают все популярные реализации RP и варьируются между сбоями, нарушением стандартного поведения и даже серьезными ошибками, позволяющими злоумышленнику полностью захватить иерархию RPKI, внедрив свой собственный якорь доверия (trust anchor).
Обход каталога / отравление кэша
Наиболее серьезная уязвимость, обнаруженная нами с помощью CURE, — это обход каталога в Routinator, программном пакете, используемом в 69.9% сетей с RPKI-проверкой. RP повсеместно используют имена объектов в качестве адресов хранения на дисках. Злоумышленник может воспользоваться отсутствием санации пользовательского ввода в уязвимых инстансах Routinator и выбрать имена, содержащие код обхода каталога '…/', чтобы разместить файлы с произвольным содержимым в любом месте на диске сервера, на котором запущен RP.
В старых версиях Routinator эта возможность могла быть использована даже для размещения нового якоря доверия в RP, контролируемого злоумышленником. Размещение нового якоря доверия в Routinator позволяло злоумышленнику бесшумно обойти всю защиту RPKI и заставить принимать произвольные RPKI-объекты, подвергая маршрутизаторы отравлению таблицы маршрутизации и перехватам BGP. В новых версиях Routinator уязвимость обхода каталогов сохранялась, но новая обработка якорей доверия нейтрализовала возможность внедрить вредоносный якорь. После нашего разоблачения проблема обхода путей была быстро исправлена, и было создано соответствующее CVE с критической оценкой (CVE-2023–39916).
Краши в RP
Большинство уязвимостей, которые мы обнаружили, были связаны с крашами RP из-за недостаточной обработки ошибок. DoS-уязвимости особенно серьезны, поскольку маршрутизаторы полагаются на доступность RP для проверки RPKI — если RP выходит из строя, маршрутизатор в конечном итоге очищает свой RPKI-кэш и принимает все BGP-анонсы, включая и попытки перехвата. Хотя большинство обнаруженных нами крашей были ошибками при парсинге, например, если данные поля были длиннее, чем указано в значении его длины, мы также обнаружили ряд внутренних ошибок в обработке. После нашей публикации все найденные нами краши были быстро исправлены разработчиками, за исключением разве что OctoRPKI.
Несоответствия RFC
В ходе анализа мы обнаружили несколько вариантов реализации, не соответствующих стандарту RPKI. Например, OctoRPKI не проверяет параметр session_id в файлах уведомлений и снапшотов. Поэтому он может парсить файлы с несогласованными идентификаторами. Эта ошибка подвергает RP атакам повторного воспроизведения (Replay Attacks). Еще одним примером несоблюдения требований RFC в OctoRPKI является то, что он обслуживает файлы из хранилищ с просроченными CRL или CRL, в которых отсутствуют обязательные расширения.
На другой стороне спектра находится Fort, который применяет проверку сертификатов гораздо строже, чем того требует стандарт, и в результате отбрасывает даже действительные сертификаты, в которых используется тип имени эмитента OrganisationName. Такие проблемы несоответствия RFC могут привести к невидимому снижению уровня защиты RPKI. Все программные компоненты и протоколы связи работают корректно, но невидимые ошибки обработки молча удаляют ROA из поля зрения маршрутизатора.
Несоответствия VRP в интернете
Мы также обнаружили, что выходные данные валидированной полезной нагрузки ROA (Validated ROA Payloads, VRPs) RP различаются в разных реализациях, даже когда обслуживается содержимое того же репозитория. Чтобы избежать расхождений в соединениях, мы запустили все четыре основных RP в одно и то же время в одной сети. Наши данные показали значительные различия в результатах, предлагаемых каждым RP.
В июне 2023 года мы увидели следующие выходные значения VRP: rpki-client (441,777), Routinator (441,770), Fort (435,002) и OctoRPKI (434,074). Различные записи в VRP указывают на несоответствие обработки во всех RP. Чтобы диагностировать эту проблему, мы запустили CURE на RPKI-объектах.
Из нашего анализа можно сделать несколько выводов. OctoRPKI отбрасывает все VRP-префиксы с длиной, превышающей максимально допустимый префикс в BGP, /24 для IPv4 и /48 для IPv6. Это привело к тому, что из VRP-кэша было отброшено не менее 1 744 префиксов. Fort отбрасывает 6 405 VRP, выданных Amazon, из-за особо строгой логики проверки сертификатов. В Fort хранилище отбрасывается, когда сертификаты используют поле атрибута OrganisationName вместо CommonName или SerialNumber. После нашего уведомления компания Amazon обновила свои объекты.
Наш анализ показывает, что в реальности несогласованность обработки в разных RP встречается часто, причем не только в результате сбоев в соединении, но и из-за различий в логике обработки в каждой из реализаций RP.
Заключение
Наше исследование показывает, что для того, чтобы сделать реализацию RPKI пригодной к промышленной эксплуатации, необходимы дополнительные исследования и работа. Мы обнаружили серьезные уязвимости в каждой из популярных реализаций RPKI, даже в таких базовых модулях, как парсинг данных.
В RP, реализующих собственный парсинг объектов, таких как Routinator и OctoRPKI, было обнаружено больше ошибок, чем в таких реализациях, как Fort или rpki-client, которые используют открытые и давно известные библиотеки, такие как OpenSSL. Хотя разнообразие различных реализаций на многих языках, конечно, желательно, эти библиотеки должны быть тщательно протестированы, прежде чем включать их в критически важные приложения сетевой безопасности.
Уязвимости, приводящие к незаметному снижению уровня защиты и даже к полному отключению ПО RP, и несоответствия между реализациями RP наносят ущерб корректности RPKI и стабильности междоменной маршрутизации. Уязвимости, обнаруженные нами в ходе исследования, подчеркивают необходимость создания инструмента тестирования, который позволил бы разработчикам RP систематически и в автоматизированном режиме анализировать уязвимости в программном обеспечении RP и быстро устранять их. Поэтому мы разработали CURE и разместили его в общий доступ на GitHub, чтобы облегчить тестирование уязвимостей программного обеспечения RPKI.
Очень важно, чтобы программное обеспечение RPKI и все его модули стали более устойчивыми к атакам, которые могут нарушить полноту и корректность данных RPKI с точки зрения маршрутизатора. Также необходим консенсус между реализациями по набору загружаемых из RPKI-репозиториев ROA.
Подробнее об этом можно узнать из нашей научно-исследовательской работы «The CURE to Vulnerabilities in RPKI Validation» («Лечение уязвимостей в RPKI-валидации»), написанной Доникой Мирдитой (Donika Mirdita), Хаей Шульманн (Haya Schulmann), Никласом Фогелем (Niklas Vogel) и Майклом Вайднером (Michael Waidner), которая будет опубликована на NDSS Symposium 2024.
Напоминаем про открытый урок сегодня вечером «Алгоритм SPF в протоколах маршрутизации OSPF и IS-IS». На нём:
1. Разберёмся с работой алгоритма SPF.
2. Реализуем протоколы OSPF и IS-IS в сети на практике.
3. Рассмотрим результат работы алгоритма SPF в сети на практике.
Записаться можно на странице курса «Network Engineer».
Habrahabr.ru прочитано 6130 раз
