На протяжении десятилетий трансляция сетевых адресов (NAT) была стандартным способом предоставления IP-адресов внутри крупных сетей, позволяя решать проблемы дефицита адресов IPv4.
Основная идея NAT заключается в том, что частные адреса остаются частными, но это предположение, возможно, уже не совсем верно (если вообще когда-либо было таковым). На конференции Black Hat USA 2026 исследователь Малкольм Стэгг, независимый исследователь и участник Synack Red Team, представил NatJack — класс атак, манипулирующих таблицей отслеживания соединений NAT.
Злоумышленник, находящийся на одной границе NAT с жертвой, может перехватывать активные соединения, отравлять DNS-ответы и вызывать отказ в обслуживании без необходимости подделки IP-адресов или доступа к широковещательному домену, как того требовали более старые атаки второго уровня. Было уведомлено тринадцать вендоров, тестирование охватило 32 продукта и конфигурации по 95 отчетам. Каждая протестированная реализация оказалась уязвимой к некоторым или всем техникам NatJack.
Стэгг не ставил перед собой задачу найти уязвимости в NAT, но он их нашел. «Я наткнулся на эту атаку совершенно случайно», — рассказал Стэгг изданию Network World. «Я заметил, что иногда получаю ответы, которые не соответствуют отправляемым мной пакетам. Это говорило мне о том, что внутри таблицы NAT происходит какое-то искажение».
Что нарушается в модели доверия NAT
NAT никогда не создавался как средство безопасности. Он появился в начале 1990-х годов как временное решение проблемы исчерпания адресов IPv4, позволяя нескольким устройствам использовать один публичный IP-адрес в предположении о доверии между пирами.
«Я думаю, это в основном восходит к недостаточной спецификации в некоторых RFC, которые просто допускают поведение, основанное на предположении, что вы находитесь в сети, где пирам доверяют», — сказал Стэгг.
NAT уже взламывали ранее. Исследователь безопасности Сэми Камкар представил NAT Pinning на DEF CON 18 и Black Hat в 2010 году — раннюю технику манипулирования поведением портов NAT. Он вернулся к проблеме десятилетие спустя с NAT Slipstreaming, представленным в 2020 году и расширенным совместно с исследователями Armis в 2021 году, который злоупотреблял отслеживанием соединений шлюза прикладного уровня (ALG) и требовал от жертвы посещения вредоносного веб-сайта. Все эти уязвимости были исправлены.
NatJack отличается. Он манипулирует таблицей NAT напрямую, не требует ALG и не требует от жертвы никаких действий, кроме наличия активного соединения через тот же NAT.
Уязвимость не ограничивается вторым уровнем. Сегментация VLAN и изоляция портов коммутатора не помогают, поскольку атака нацелена на общую инфраструктуру NAT на третьем и четвертом уровнях, а не на локальный широковещательный домен. Уязвимость была подтверждена в Windows, Linux и macOS, несмотря на отсутствие общего кодовой базы NAT, что указывает на общее проектное предположение, а не на изолированную ошибку.
Четыре техники атаки, одна общая слабость
NatJack включает четыре различные техники, все основанные на одной и той же слабости в том, как таблицы NAT отслеживают соединения.
- Перехват TCP-соединения. Злоумышленник принудительно переводит соединение жертвы в закрытое состояние с помощью поддельных пакетов, а затем заменяет полученную запись таблицы на запись, указывающую на злоумышленника. Механизм TIME-WAIT Assassination из RFC 1337, идентифицированный Стэггом, позволяет это сделать за несколько пакетов, а не за стандартное время ожидания соединения.
- Отравление DNS-ответов. Техника перехватывает и изменяет UDP-ответы DNS, проходящие через NAT, перенаправляя запросы жертвы без ее ведома.
- Отказ в обслуживании. Злоумышленник истощает саму таблицу NAT, нарушая связность для всех устройств, использующих этот NAT.
- Идентификация порта соединения. Злоумышленник определяет, какой порт NAT назначил активному соединению; эта информация может поддерживать три другие техники.
Раскрытие и неоднозначная реакция вендоров
Стэгг ответственно раскрыл уязвимость, хотя реакция вендоров была весьма разнообразной — от официальных исправлений до полного отказа.
Команда безопасности ядра Linux изначально отклонила отчет, назвав его «полностью фальшивым». Стэгг сказал, что такой ответ застал его врасплох. «Я был довольно удивлен этим, — сказал Стэгг. — Получить такой ответ было несколько неожиданно и немного обескураживающе».
В конечном итоге ядро было исправлено по запросу Microsoft для поддержки Azure Kubernetes Service, что привело к появлению CVE-2026-63913. Собственная уязвимость NAT от Microsoft, затрагивающая Hyper-V, получила идентификатор CVE-2026-56181.
Другие вендоры отказались классифицировать находки как уязвимости. «Эти отчеты представляют собой проектные ограничения NAT, а не уязвимости безопасности», — заявил Cisco PSIRT. «Существуют задокументированные меры смягчения для Cisco Secure Firewall и Cisco IOS XE, которые предотвратили бы большинство, если не все, из этих проблем».
Apple заняла аналогичную позицию. «Мы определили, что данное поведение отражает известное ограничение транспортного уровня, а не уязвимость», — заявила служба безопасности продуктов Apple. «Современные модели безопасности предполагают, что локальная сеть может быть враждебной. Именно поэтому мы продолжаем полагаться на сквозное шифрование, такое как TLS».
Стэгг отметил, что, хотя шифрование смягчает наихудшие последствия NatJack, оно не устраняет риск. «Шифрование здесь очень помогает, потому что злоумышленник все еще может перехватить соединение, но если он это сделает, он не сможет отправлять или получать какие-либо данные по этому соединению в незашифрованном виде, — сказал Стэгг. — Однако злоумышленник все еще может нацелиться на любое из этих соединений и разорвать его».
Обнаружение и смягчение
Даже при отсутствии полных исправлений сетевые специалисты могут предпринять шаги для снижения риска. Стэгг предлагает следующее:
- Мониторинг индикаторов компрометации. Следите за полной или почти полной таблицей NAT, потоками TCP- или UDP-пакетов в широком диапазоне портов, появлением одного и того же IP-адреса в двух физических местоположениях, а также аномальными последовательностями SYN- или RST-пакетов.
- Включите защиту исходного IP-адреса. Активируйте такие механизмы защиты, как IP Source Guard, для блокировки поддельных пакетов на маршрутизаторе или межсетевом экране.
- Сегментируйте ненадежный трафик. Поместите ненадежных пользователей в отдельную подсеть или VLAN и ограничьте количество соединений на одного клиента примерно до 10 000.
- Отключите свободные режимы соединений. Отключите свободное отслеживание соединений, сохранение портов и независимое от конечной точки сопоставление там, где это поддерживается.
- Ограничьте сетевой доступ контейнеров. Отключите сетевой доступ для ненадежных контейнеров и рабочих нагрузок Kubernetes, избегайте запуска от root и удалите стандартные возможности.
- Изолируйте облачные рабочие нагрузки. Не размещайте ненадежные и доверенные рабочие нагрузки на одном шлюзе NAT, используйте выделенные IP-адреса для бессерверных рабочих нагрузок.
«Один из вариантов атаки все еще работает в случаях, когда злоумышленник и жертва находятся в разных подсетях», — сказал Стэгг.
Стэгг сказал, что основной урок NatJack выходит за рамки любого отдельного исправления.
«Многие сети уязвимы для этого, и вы не всегда можете полагаться на изоляцию второго уровня, которая существует, — сказал Стэгг. — Когда вы полагаетесь на исторические проектные решения, эти модели угроз могут быть не такими, как раньше. Важно посмотреть на эти проектные предположения и проверить, не требуются ли какие-либо обновления, основанные на новых моделях угроз».
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Sean Michael Kerner
