Исследователь представил новый класс атак, затрагивающий сетевые устройства, выполняющие трансляцию сетевых адресов (NAT). Методика, получившая название NatJack, позволяет злоумышленнику, находящемуся за NAT-устройством, перехватывать существующие TCP-соединения, искажать DNS-ответы и нарушать работу сервисов. Проблема носит системный характер и связана не с конкретным вендором, а с фундаментальными допущениями, заложенными в архитектуру NAT десятилетия назад.
Уязвимость NatJack
Суть атаки заключается в манипуляции таблицей NAT-состояний. Злоумышленник формирует поддельные пакеты, которые изменяют или заменяют записи трансляции в реальном времени. В результате трафик, предназначенный для легитимного соединения жертвы, перенаправляется на конечную точку, контролируемую атакующим. При этом внешний сервер продолжает считать соединение подлинным, что позволяет внедрять вредоносные данные или полностью перехватывать сеанс.
Серия атак включает несколько сценариев: перехват TCP-соединений с подменой адресов как на стороне клиента, так и на стороне сервера; перехват UDP-DNS-запросов с подменой ответов для перенаправления жертвы на вредоносные домены; раскрытие информации о внешнем NAT-порте; а также отказ в обслуживании из-за повреждения или удаления записей для активных потоков. По сути, эти методы аналогичны по последствиям атакам через подмену ARP-запросов, но работают даже в случаях, когда жертва и атакующий находятся в разных широковещательных доменах, например в разных подсетях или VLAN, имея общее только NAT-устройство.
Особую обеспокоенность вызывает масштаб охвата. Тестирование показало, что все проверенные NAT-устройства - от потребительских маршрутизаторов до корпоративных решений и виртуальных платформ - уязвимы к некоторым или всем вариантам NatJack. Проблема затрагивает контейнерные сетевые стеки, включая мосты Docker и Kubernetes, а также NAT-реализации гипервизоров. Многие платформы проектировались исходя из предположения, что внутренние арендаторы или рабочие нагрузки считаются доверенными. Однако в современных средах, где скомпрометированные контейнеры, виртуальные машины или пользовательские устройства соседствуют с чувствительными сервисами на общей NAT-инфраструктуре, это допущение теряет силу.
Для домашних пользователей риск эксплуатации в целом невысок. Атака требует, чтобы за тем же маршрутизатором уже находилось недоверенное или скомпрометированное устройство с достаточными привилегиями для генерации поддельных пакетов. В типичном домашнем сценарии такая ситуация маловероятна. В то же время для предприятий, провайдеров услуг и облачных арендаторов угроза значительно выше. Типовые корпоративные сети смешивают недоверенные конечные точки пользователей, сервисы, доступные из интернета, и ценные внутренние системы за общими маршрутизаторами, межсетевыми экранами, NAT-шлюзами и балансировщиками нагрузки. В такой среде атакующий, получивший доступ к любому внутреннему хосту или рабочей нагрузке за NAT, может вмешиваться в трафик других чувствительных систем, даже если они находятся в других подсетях или VLAN.
Вендоры уже начали внедрять частичные меры защиты. Microsoft устранила связанную с NatJack проблему в своей Windows NAT, влияющую на сценарии Hyper-V, через CVE-2026-56181. Обновление снижает возможность атак с подменой адреса на стороне клиента. В ядре Linux подсистема Netfilter получила патчи CVE-2026-63913 в версии 7.1 и новее, которые исправляют конкретную ошибку кода и добавляют меры, повышающие сложность манипуляции NAT-состоянием. Впрочем, эти изменения не считаются полным решением. FreeBSD в версии 15.0 унаследовала от OpenBSD усиление для Packet Filter, которое значительно уменьшает практическую реализуемость атак с подменой как на стороне клиента, так и на стороне сервера, хотя и оставляет пространство для дальнейших улучшений.
Облачные провайдеры также реагируют. AWS подтвердила, что проверила и укрепила свои сервисы NAT Gateway и Network Load Balancer. Внесённые изменения улучшают проверку состояния соединений, особенно обработку TCP-пакетов со сбросом (RST), и увеличивают время удержания портов, чтобы блокировать паттерны манипуляции NAT-потоками, описанные в исследовании. По заявлению AWS, успешная эксплуатация потребовала бы от атакующего контроля над EC2-инстансом в том же виртуальном облаке (VPC), что и целевое соединение, а в ряде случаев - доступа к внешнему серверу с возможностью подделки IP-адресов. Новые меры нейтрализуют эти угрозы без необходимости действий со стороны клиентов.
Для организаций главная рекомендация - перестать рассматривать NAT как защитный механизм. Устройства трансляции адресов не обеспечивают границу безопасности, а при определённых условиях могут стать точкой для бокового перемещения. Необходимо оперативно устанавливать обновления вендоров, пересматривать мультитенантные схемы, в которых недоверенные и высокоценные рабочие нагрузки используют общий NAT, и усиливать сегментацию на уровне маршрутизаторов, межсетевых экранов и узлов. Дополнительно рекомендуется использовать шифрование TLS и DNS-безопасность, чтобы затруднить перехват данных даже в случае компрометации NAT-устройства.
NatJack демонстрирует, что многолетние предположения о "кооперативном" поведении сетевых устройств устарели. Традиционные методы защиты, полагающиеся на доверие к внутренним сегментам, больше не соответствуют реалиям враждебных мультитенантных сред. Уязвимость затрагивает широкий спектр оборудования и программного обеспечения, и полное устранение проблемы потребует пересмотра принципов построения сетевой инфраструктуры, а не только точечных исправлений. Пока вендоры выпускают дополнительные патчи, организациям следует применять компенсирующие меры и внимательно отслеживать индикаторы атак, такие как переполнение NAT-таблиц, необычные последовательности TCP-пакетов или подозрительные всплески RST-запросов.
Ссылки
