На Black Hat USA 2026 независимый исследователь Malcolm Stagg, участник команды Synack Red Team, представил NatJack — класс атак, манипулирующих таблицей отслеживания соединений NAT. Атакующий, находящийся за той же NAT-границей, что и жертва, может перехватывать активные соединения, отравлять DNS-ответы и устраивать отказ в обслуживании — без спуфинга IP-адресов и без доступа к широковещательному домену, которые требовались старым атакам второго уровня.
Масштаб проблемы впечатляет: уведомлены 13 вендоров, тесты покрыли 32 продукта и конфигурации в рамках 95 отчётов — и каждая протестированная реализация оказалась уязвима хотя бы к части техник NatJack.
NAT не был задуман как защита
Ключевой тезис исследования: NAT появился в начале 1990-х как временное решение нехватки IPv4-адресов и строился на допущении доверия между пирами за одной границей. «Проблема восходит к недоопределённости в RFC — там разрешено поведение, основанное на предположении, что вы находитесь в сети, где пиры доверяют друг другу», — говорит Stagg.
Нашёл он проблему случайно: заметил, что иногда получает ответы, не соответствующие отправленным пакетам. «Это говорило мне, что внутри таблицы NAT происходит какая-то порча», — объясняет исследователь.
Атаки на NAT известны и раньше: NAT Pinning Samy Kamkar показал ещё в 2010 году на DEF CON 18 и Black Hat, а NAT Slipstreaming (2020, расширена с исследователями Armis в 2021) злоупотребляла отслеживанием соединений через Application Level Gateway и требовала, чтобы жертва открыла вредоносный сайт. Все эти проблемы давно закрыты патчами. NatJack отличается принципиально: он работает напрямую с таблицей NAT, не требует ALG и никаких действий жертвы — достаточно, чтобы у неё было активное соединение через тот же NAT.
Защита второго уровня не спасает: VLAN-сегментация и изоляция портов коммутатора бесполезны, поскольку атака целится в общую NAT-инфраструктуру на уровнях L3/L4, а не в локальный широковещательный домен. Уязвимость подтверждена на Windows, Linux и macOS — при том, что общего кода NAT у этих систем нет, что указывает на общий проектный дефект, а не на изолированную ошибку.
Четыре техники на одном слабом месте
- Перехват TCP-соединений: атакующий поддельными пакетами переводит соединение жертвы в закрытое состояние и подменяет запись таблицы на свою. Механизм TIME-WAIT Assassination из RFC 1337 позволяет сделать это за несколько пакетов, а не за стандартное время таймаута.
- Отравление DNS: перехват и подмена UDP-DNS-ответов, проходящих через NAT, перенаправляет запросы жертвы незаметно для неё.
- Отказ в обслуживании: исчерпание самой таблицы NAT разрывает связь для всех устройств за этой границей.
- Идентификация порта: определение того, какой порт NAT назначил активному соединению, — вспомогательная техника для остальных трёх.
Реакция вендоров разная
Раскрытие проблемы прошло по-разному: команда безопасности ядра Linux сначала отклонила отчёт, назвав его «совершенно нелепым» (totally bogus). Патч в итоге появился по запросу Microsoft для поддержки Azure Kubernetes Service — ему присвоен CVE-2026-63913. Уязвимость NAT в Windows (затрагивает Hyper-V) получила CVE-2026-56181.
Cisco и Apple отказались считать находку уязвимостью. Cisco PSIRT назвал это «проектными ограничениями NAT, а не уязвимостями безопасности», сославшись на документированные меры для Cisco Secure Firewall и IOS XE. Apple заявила, что поведение отражает «известное ограничение транспортного уровня», а современные модели безопасности предполагают, что локальная сеть может быть враждебной, поэтому компания полагается на сквозное шифрование вроде TLS.
Stagg признаёт: шифрование смягчает худшие последствия, но не устраняет риск. «Атакующий всё равно может перехватить соединение — просто не сможет передавать по нему данные открыто. Зато он может точечно рвать любые соединения», — поясняет он.
Как снизить риск до выхода патчей
Исследователь предлагает сетевые меры: следить за признаками компрометации — почти полной или полной таблицей NAT, флудом TCP/UDP по широкому диапазону портов, появлением одного IP-адреса в двух физических точках, аномальными последовательностями SYN/RST; включать защиту источника (например, IP Source Guard); сегментировать недоверенный трафик в отдельную подсеть или VLAN и ограничивать соединения на клиента примерно 10 тысячами; отключать «свободные» режимы отслеживания — loose connection tracking, сохранение портов и endpoint-independent mapping; ограничивать сетевой доступ недоверенных контейнеров и Kubernetes-нагрузок (не запускать от root, убирать лишние capabilities); изолировать облачные нагрузки — держать доверенные и недоверенные рабочие нагрузки на разных NAT-шлюзах, использовать выделенные IP для serverless. Один из вариантов атаки работает и тогда, когда атакующий с жертвой находятся в разных подсетях.
Урок NatJack выходит за рамки конкретного патча: «На многих сетях нельзя полагаться на изоляцию второго уровня. Когда опираешься на исторические проектные решения, их модели угроз могут не соответствовать сегодняшним реалиям», — резюмирует Stagg.
Источник: csoonline.com