Переполнение буфера в протоколе NGOAM на коммутаторах Cisco Nexus открывает путь к удалённому выполнению кода

Уязвимость в реализации протокола NGOAM операционной системы Cisco NX-OS позволяет удалённому злоумышленнику выполнить произвольный код на коммутаторах Cisco Nexus серий 3000 и 9000. Причиной стала запись данных за границы выделенного участка памяти в стеке. Такая ошибка даёт возможность перехватить управление устройством или обрушить его работу. Базовая оценка по CVSS 3.1 составляет 9,8 из 10, по устаревшей методике CVSS 2.0 - 10 из 10. Сведения о проблеме внесены в Банк данных угроз безопасности информации (BDU) под номерами BDU:2026-16097 и BDU:2026-16098. Им соответствуют идентификаторы CVE-2026-76485 и CVE-2026-76486.

Детали уязвимостей

Речь идёт о двух почти идентичных уязвимостях. Обе связаны с обработкой пакетов протокола NGOAM. Этот протокол применяют для диагностики и мониторинга сетевых соединений на уровне оборудования. Он работает в обход обычных механизмов управления и не требует от отправителя предварительной аутентификации. Поэтому любой узел, имеющий сетевой доступ к коммутатору, может отправить туда специально сформированный запрос. Достаточно, чтобы в ответ на некорректные данные устройство записало во внутренний буфер больше информации, чем там помещается.

Механика атаки выглядит так. Злоумышленник отправляет на устройство пакет с завышенной длиной или нестандартной структурой полей. Обработчик NGOAM при этом не проверяет размер входных данных. В результате содержимое выходит за пределы стека и перезаписывает соседние области памяти. Грамотно подобранные данные позволяют подменить адрес возврата и передать управление на чужой код. Если это не удаётся, устройство всё равно теряет работоспособность. По классификации CWE ошибка относится к типу CWE-121, то есть к переполнению буфера в стеке.

Важная деталь: для эксплуатации не нужны ни учётная запись, ни физический доступ к портам, ни действия со стороны пользователя. Вектор атаки - сетевой, сложность - низкая. Это следует из описания CVSS, где указаны параметры AV:N, AC:L, PR:N и UI:N. Подобная комбинация встречается нечасто. Обычно производители сетевого оборудования закрывают служебные протоколы хотя бы паролем или ограничением по адресам.

Коммутаторы серий Nexus 3000 и 9000 занимают верхний уровень центров обработки данных. Их ставят в ядро сети и на агрегацию. Через них проходит трафик между серверами, системами хранения и внешними каналами. Следовательно, компрометация такого устройства означает контроль над значительной частью инфраструктуры. Злоумышленник может перенаправлять потоки данных, отключать сегменты сети или закрепляться на коммутаторе надолго. Отказ в обслуживании тоже обходится дорого. Один неисправный коммутатор в ядре способен остановить работу целого узла связи.

Современные версии NX-OS построены на ядре Linux. Поэтому выполнение произвольного кода на коммутаторе открывает доступ к полноценной операционной среде, а не только к функциям коммутации. Наряду с этим на сетевом оборудовании редко ставят средства защиты конечных точек. Обнаружить чужой код на коммутаторе сложнее, чем на сервере. Журналы устройства сами по себе редко выдают присутствие нарушителя, если он аккуратен.

Под удар попадают организации с крупными сетями. Это операторы связи, банки, промышленные предприятия, государственные структуры и облачные провайдеры. Особенно внимательными стоит быть тем, кто не изолировал управляющий контур от пользовательских сетей. Если интерфейсы управления доступны из общей сети, вероятность успешной атаки резко возрастает. Вместе с тем даже закрытый контур не даёт полной гарантии. Внутренний нарушитель с доступом к любому узлу той же сети получает те же возможности.

Производитель подтвердил наличие уязвимостей. Информация о готовых эксплойтах пока уточняется, однако публичных сообщений о реальных атаках нет. Это не отменяет риска. Практика показывает, что после раскрытия сведений о подобных ошибках злоумышленники начинают проверять уязвимые устройства в интернете уже через несколько дней. Причём поиск жертв идёт автоматически, без участия человека.

Производитель исправил ошибку в актуальных сборках NX-OS. Затронуты ветки от 9.2 до 10.6, поэтому список версий широк. Владельцам оборудования нужно сверить текущую сборку с рекомендациями и обновиться. Порядок действий приведён в бюллетене производителя. Тем, кто не может обновиться сразу, стоит ограничить доступ к служебным протоколам. Здесь помогают списки разрешённых адресов, отдельный контур управления и запрет на приём пакетов NGOAM из недоверенных сегментов. Кроме того, полезно проверить журналы на предмет необычных обращений к диагностическим службам.

Отдельного разговора заслуживает подход к управлению сетью. Служебные протоколы часто включают по умолчанию и забывают о них. При этом они обходят обычные механизмы аутентификации. Поэтому аудит таких служб должен идти параллельно с установкой обновлений. Обновление закрывает конкретную ошибку, но не убирает привычку оставлять диагностические интерфейсы открытыми. Стоит помнить и о том, что служебные функции редко попадают в поле зрения службы информационной безопасности, тогда как именно они всё чаще становятся точкой входа.

Детали уязвимостей

Ссылки