dilan-diaz/point-to-point-protocol-daemon-rce-vulnerability-cve-2020-8597-
Шри-Ланкийский институт информационных технологий
Задание 1
M. P. D. M. Dias
IT19165530
MLB_WD_Y2S1_13.1
Уязвимость RCE в демоне Point to Point Protocol
(CVE-2020-8597)
Системное и сетевое программирование – IE2012
Содержание
Введение
Протокол Point-to-Point (PPP) — это полнодуплексный протокол, который позволяет инкапсулировать и передавать простые данные через инфраструктуру уровня 2 (канального уровня), начиная от коммутируемого доступа (dial-up) и широкополосных DSL-соединений и заканчивая виртуальными частными сетями (VPN) с SSL-шифрованием. Поскольку эти протоколы не поддерживают связь «точка-точка», PPP также используется для организации работы IP и TCP поверх двух напрямую соединённых узлов. Pppd — это демон, используемый в Unix-подобных операционных системах для управления установлением PPP-сеансов и их завершением между двумя узлами.
PPP — это протокол, используемый для создания интернет-соединений через коммутируемые модемы, DSL-соединения и некоторые другие виды соединений «точка-точка» через виртуальные частные сети (VPN), такие как протокол туннелирования «точка-точка» (PPTP). Программа pppd также может аутентифицировать узел, подключающийся к сети, и/или предоставлять узлу данные аутентификации с использованием различных протоколов аутентификации, таких как EAP.
Из-за ошибки в обработке пакета протокола расширяемой аутентификации (EAP) в демоне Point-to-Point Protocol (pppd) неаутентифицированный удалённый злоумышленник может вызвать переполнение буфера стека, что может позволить произвольное выполнение кода в целевой системе. Эта уязвимость вызвана ошибкой проверки размера входных данных перед копированием предоставленных данных в память. Поскольку проверка размера данных выполняется некорректно, в память могут быть скопированы случайные данные, что может вызвать утечку файлов и способствовать непреднамеренному выполнению кода.
Уязвимость кроется в логике кода разбора EAP, а именно в функциях eap_request() и eap_response() в файле eap.c, которые вызывает сетевой обработчик ввода. Эти функции принимают указатель и длину, используя первый байт как тип. Если типом является EAPT MD5CHAP(4), то функция обращается к встроенному полю длины размером 1 байт. Логика этого кода предназначена для проверки того, что встроенная длина меньше общей длины пакета. После этой проверки код пытается скопировать предоставленные данные (имя хоста), которые располагаются в локальном стековом буфере после поля встроенной длины. Эта проверка границ некорректна и допускает копирование в память данных произвольной длины.
Ещё одна логическая ошибка приводит к тому, что функция eap_input() не проверяет, был ли EAP согласован в процессе протокола управления линией (LCP). Это позволяет неаутентифицированному злоумышленнику отправлять EAP-пакет, даже если pppd отказался согласовывать аутентификацию из-за отсутствия поддержки EAP или из-за несоблюдения согласованной предварительно общей кодовой фразы на этапе LCP. В eap_input() небезопасный код pppd всё равно должен обработать EAP-пакет и вызвать переполнение буфера стека. Эти непроверенные данные неизвестного размера могут быть использованы для компрометации памяти целевого устройства. Кроме того, pppd работает с высокими привилегиями (системными или root) и взаимодействует с драйверами ядра.
Программа pppd также используется совместно с проектом lwIP (lightweight IP) для предоставления функциональности pppd на малых компьютерах. Стандартные установки lwIP не подвержены этому переполнению буфера. Однако если использовать исходный код lwIP и явно изменить его для разрешения EAP на этапе компиляции, программа может оказаться уязвимой к переполнению буфера.
CVE-2020-8597 — это ошибка переполнения буфера в pppd, вызванная логическим дефектом в обработчике пакетов протокола расширяемой аутентификации (EAP). Неавторизованный удалённый злоумышленник, отправляющий специально созданный EAP-пакет уязвимому PPP-клиенту или серверу, может вызвать отказ в обслуживании или произвольное выполнение кода. Поскольку pppd работает совместно с драйверами ядра и обладает высокими привилегиями, такими как device или даже core, любое выполнение кода также может быть осуществлено с теми же привилегиями.
Сведения об авторе обнаружения уязвимости
Критическая проблема, обнаруженная исследователем безопасности IOActive Ильёй ван Спрунделем (Ilja Van Sprundel), представляет собой ошибку переполнения буфера стека, возникающую из-за логической ошибки в анализаторе модуля протокола расширяемой аутентификации (EAP) приложения pppd — расширения, обеспечивающего поддержку дополнительных методов аутентификации в PPP-соединениях.
Эта уязвимость, отслеживаемая как CVE-2020-8597 с оценкой CVSS 9.8, может быть использована неавторизованными злоумышленниками для удалённого выполнения произвольного кода на затронутых устройствах и получения полного контроля над ними.
Как была обнаружена уязвимость
Эта уязвимость вызвана ошибкой проверки размера входных данных перед копированием данных в память. Поскольку проверка размера данных выполняется некорректно, в память могут быть скопированы случайные данные, что может вызвать повреждение памяти и, вероятно, способствовать выполнению неавторизованного кода.
Уязвимость находится в логике кода разбора EAP, а именно в функциях eap_request() и eap_response() в файле eap.c, которые вызываются сетевым обработчиком ввода.
Ошибочно полагать, что pppd защищён, если EAP не разрешён или если EAP не был инициирован удалённым узлом с использованием пароля или кодовой фразы. Это связано с тем, что неаутентифицированный злоумышленник всегда может отправить непрошеный EAP-пакет, чтобы вызвать переполнение буфера.
Уязвимость была выявлена в демоне протокола Point-to-Point (PPP), или pppd. PPP — это протокол уровня 2, используемый для установления соединений через коммутируемые модемы, DSL-подключения и многие другие физические сети, включая мобильные сети. PPP был расширен дополнительными протоколами, такими как протокол туннелирования «точка-точка» (PPTP), который используется в виртуальных частных сетях (VPN) для обеспечения зашифрованных соединений.
В этой ситуации команда SEI CERT объединила усилия с аналитиком безопасности Ильёй ван Спрунделем (IOActive), обнаружившим эту ошибку, и разработчиком Полом Маккеррасом (OZlabs), который сопровождает исходный код, чтобы детально изучить проблему и найти решение. Проблема заключалась в переполнении буфера в исходном коде pppd, вызванном ошибкой в булевом выражении и реализации условных операторов, ставших его следствием. Приведённый ниже оператор можно обмануть, заставив его принять входные данные неизвестной длины и скопировать их в стековый буфер. Это обычно называют переполнением стека или переполнением буфера стека.
if (vallen >= len + sizeof(rhostname)) { // Copy to buffer rhostname
Исправление уязвимости заключалось в простой замене приведённого выше оператора на следующее булево выражение.
if (len-vallen >= sizeof(rhostname)) { // Copy to buffer rhostname
Пол присвоил этой ошибке идентификатор CVE-2020-8597 и внёс исправление в исходный код, который он сопровождает. Обновление, необходимое для устранения ошибки, незначительное и требует всего лишь нескольких строк кода. Тем не менее эта уязвимая технология присутствует в тысячах библиотек программных проектов. Она используется более чем в 100 компаниях, предлагающих устройства доступа к сети, — от домашних маршрутизаторов до корпоративного сетевого оборудования. Поскольку эта уязвимость затрагивает все PPP-клиенты и PPP-серверы, она также затрагивает интернет-провайдеров (ISP).
Когда была обнаружена уязвимость
4 марта 2020 года исследователи из Центра координации CERT (CERT/CC) опубликовали бюллетень об уязвимости № 782301, касающийся критической уязвимости в демоне Point-to-Point Protocol (pppd) версий с 2.4.2 по 2.4.8; авторство обнаружения приписывается Илье ван Спрунделю из IOActive.
Какой ущерб она может нанести
Отправляя непрошеный EAP-пакет уязвимому PPP-клиенту или серверу, неавторизованный удалённый злоумышленник может вызвать повреждение памяти в процессе pppd, что может привести к произвольному выполнению кода.
По словам исследователя, версии демона Point-to-Point Protocol с 2.4.2 по 2.4.8 — все версии, выпущенные за последние 17 лет, — подвержены этой новой ошибке удалённого выполнения кода. Некоторые из широко используемых популярных дистрибутивов Linux, перечисленных ниже, уже были отмечены как затронутые; вероятно, уязвимы также и другие проекты.
Debian Ubuntu SUSE Linux Fedora NetBSD Red Hat Enterprise Linux
Кроме того, число других уязвимых приложений и устройств (некоторые из них перечислены ниже), которые поставляются вместе с pppd, вероятно, также огромно, что предоставляет хакерам широкую поверхность атаки.
Cisco CallManager TP-LINK products OpenWRT Embedded OS Synology products
Из-за ошибки в обработке пакетов протокола расширяемой аутентификации (EAP) в демоне Point-to-Point Protocol (pppd) неаутентифицированный удалённый злоумышленник может вызвать переполнение буфера стека, что может позволить произвольное выполнение кода в целевой системе. Эта уязвимость вызвана ошибкой проверки размера входных данных перед копированием предоставленных данных в память. Поскольку проверка размера данных некорректна, в память могут быть скопированы произвольные данные, что приведёт к повреждению памяти и, возможно, к выполнению нежелательного кода.
Какие существуют техники эксплуатации
Критическая проблема — это уязвимость переполнения буфера стека, возникающая из-за логической ошибки в анализаторе пакетов протокола расширяемой аутентификации (EAP) в программном обеспечении pppd — расширении, обеспечивающем поддержку дополнительных методов аутентификации в PPP-соединениях.
Для этого злоумышленнику достаточно отправить непрошеный повреждённый EAP-пакет уязвимому PPP-клиенту или серверу через прямое последовательное соединение, ISDN, Ethernet, SSH, socket CAT, PPTP, GPRS или ATM-сети.
Кроме того, поскольку pppd часто работает с высокими привилегиями и взаимодействует с драйверами ядра, эта ошибка может позволить злоумышленникам выполнить вредоносный код с привилегиями системы или root. Какой метод эксплуатации был выбран
Для эксплуатации уязвимого клиента использован метод удалённого выполнения кода. Удалённое выполнение кода (RCE) — это возможность киберзлоумышленника проникнуть в устройство, контролируемое другим лицом, и вносить в него изменения без разрешения, независимо от того, где физически находится устройство. RCE позволяет злоумышленнику получить контроль над компьютером или сервером путём запуска произвольного вредоносного программного обеспечения.
Для тестирования я использую две виртуальные машины на одном компьютере. Одна выступает в роли сервера, другая — в роли клиента. Для соединения виртуальных машин я устанавливаю SSH. Используя их IP-адреса, я подключаю виртуальную машину Fedora 29 как серверную сторону, а виртуальную машину Kali Linux — как уязвимую клиентскую сторону. Следуя инструкциям, я настроил pppoe-server. Затем я включил режим отладки, указал файл журнала и добавил в файл журнала '/etc/ppp/pppoe-server-options' следующее. Затем настроил pppoe-client, выполнив команду 'sudo pppoeconf'. Наконец, с помощью Python-кода можно осуществить эксплуатацию уязвимого клиента. Кроме того, отправив непрошеный EAP-пакет уязвимому PPP-клиенту, удалённый злоумышленник может вызвать повреждение памяти в процессе pppd, что может позволить произвольное выполнение кода.
Скриншоты эксплуатации
Пинг уязвимого клиента
Установка SSH на сервер
Получение root-доступа на стороне клиента
После получения root-доступа клиента
Включение SSH на стороне клиента
Сбой
Результат
Заключение
GitHub Security Lab приходит на помощь
Изучая новейшую инициативу GitHub по защите, Виджай Сарвепалли (Vijay Sarvepalli) захотел выявить возможности использования API GitHub и решений CodeQL для решения этой проблемы и использовал код, чтобы предложить исправление пользователям программных репозиториев. Он связался с нашим руководителем направления по защите государственных структур Алланом Фридманом (Allan Friedman) — директором по инициативам в области кибербезопасности Национального управления по телекоммуникациям и информации (NTIA) Министерства торговли США, — который объединил ряд организаций, включая GitHub, для создания спецификации состава программного обеспечения (SBOM). Аллан познакомил Виджая Сарвепалли с сотрудниками GitHub, отвечающими за конфиденциальность, а они связали меня с руководителем GitHub Security Lab Нико Вайсманом (Nico Waisman).
Нико и его международная команда в GitHub Security Lab быстро нашли способ применить свой механизм исправления уязвимостей к этой проблеме. Они задействовали автоматическую технологию-«робота», которая связалась с владельцами всех репозиториев, затронутых этой ошибкой. Владельцам репозиториев достаточно было выполнить несколько быстрых действий, чтобы исправить и защитить свои скопированные или форкнутые версии программы pppd, устранив ошибку. Эта инициатива сообщества привела нас к этапу, на котором технология исправлялась. Это предложило модульный и своевременный подход к внесению улучшений в исходный код для повышения защиты. В течение четырёх дней после автоматических обновлений GitHub Security Lab 1896 владельцев репозиториев получили подробную информацию об ошибке и возможность исправить её в несколько кликов. По меньшей мере 42 из этих владельцев репозиториев одобрили автоматический патч; ещё 13 подтвердили, что проблема уже исправлена. Без автоматизации потребовалось бы несколько дней, чтобы связаться с затронутыми владельцами репозиториев и исправить их приложения.
Вызов, стоящий перед Министерством обороны США, и роль CERT в будущем программного обеспечения
Будучи федеральным центром исследований и разработок (FFRDC), Институт программной инженерии (SEI) Университета Карнеги — Меллона и его подразделение CERT постоянно сталкиваются с вызовами, с которыми Министерство обороны США (DoD) сталкивается в киберпространстве. Главный специалист DoD по информационным технологиям (CIO) Терри Халворсен (Terry Halvorsen), известный евангелист кибербезопасности, в своём выступлении на конференции AFCEA заявил, что «оборонительные действия и контрмеры в киберпространстве будут происходить за миллисекунды». Такие желаемые оборонительные кибердействия не могут выполняться вручную или с помощью громоздких коммуникационных процессов. Они должны обеспечиваться программными средствами и автоматизироваться в максимально возможной степени, чтобы ограничить проблемы, присущие существующим моделям установки исправлений с участием человека.
В ходе деятельности по управлению потенциальными угрозами мы рассчитываем выявлять ситуации, в которых можно использовать стимулы (например, это партнёрство с GitHub Security Lab) для ускорения исправления исходного кода, устраняющего уязвимости информационной безопасности. Хотя мы понимаем, что это не решит всех проблем защиты информации и не заменит качественные методы программирования, мы осознаём, что ошибки, как правило, обнаруживаются в программном обеспечении уже после его публикации. Когда информация пронизывает нашу повседневную жизнь, защитить её можно только путём своевременного выявления уязвимостей — и, если возможно, путём автоматизации как выявления, так и реагирования.
Ссылки
• https://www.kb.cert.org/vuls/id/782301/ • https://thehackernews.com/2020/03/ppp-daemon-vulnerability.html • https://www.tenable.com/blog/cve-2020-8597-buffer-overflow-vulnerability-in-point-to-point-protocol-daemon-pppd • https://insights.sei.cmu.edu/cert/2020/03/security-automation-should-begin-at-the-source.html • https://packetstormsecurity.com/files/156802/pppd-2.4.8-Buffer-Overflow.html • https://www.drizgroup.com/driz_group_blog/what-is-remote-code-execution-attack-how-to-prevent-this-type-of-cyberattack • https://github.com/WinMin/CVE-2020-8597 • http://www.howtodoityourself.org/pppoe-server-how-to-do-it-yourself.html