Статья Пентест VPN-инфраструктуры: методология проверки Check Point, Fortinet и Cisco на уязвимости аутентификации

8 июня 2026 года Check Point раскрыл CVE-2026-50751 - критический обход аутентификации (CVSS 9.3) в VPN-шлюзах на Gaia OS через deprecated-протокол IKEv1. Уязвимость уже в CISA KEV, эксплуатация шла с 7 мая, скомпрометировано несколько десятков организаций. Связь с ransomware-кампаниями отмечена в KEV (конкретная атрибуция группировки не подтверждена на момент публикации). CISA дала три дня на патч - дедлайн 11 июня. EPSS - 0.7010, top 1% всех известных CVE по вероятности эксплуатации в ближайшие 30 дней.

Deprecated-протокол, который должен был умереть годы назад, снова стал точкой входа. Ниже - пошаговая методология пентеста VPN-инфраструктуры трёх вендоров: Check Point, Fortinet и Cisco, с фокусом на уязвимости аутентификации. Именно через них сегодня ломают корпоративный периметр.

Бизнес-логика атаки: зачем ломают VPN-шлюзы​

VPN-шлюз - одна из немногих точек корпоративного периметра, доступных из интернета by design. В терминах MITRE ATT&CK его компрометация закрывает сразу Initial Access - через Exploit Public-Facing Application (T1190) и External Remote Services (T1133) - и открывает дорогу к Credential Access через T1212. Атакующий с VPN-сессией без легитимных учётных данных оказывается "внутри": для IDS/IPS он выглядит как обычный удалённый сотрудник. Подробнее - в нашем статье о уязвимости iot устройств.

По данным IBM X-Force Threat Intelligence Index 2025, среднее время между публикацией CVE и устранением - 29 месяцев. Для VPN-шлюза это значит: уязвимость, раскрытая в июне, с высокой вероятностью останется непатченной до 2028 года. CrowdStrike Global Threat Report 2025 фиксирует, что 86% атак в 2024 году имели финансовую мотивацию (eCrime). VPN-шлюз как точка входа для ransomware - не теория: CVE-2026-50751 в CISA KEV с ransomware-флагом это подтверждает.

Цепочка атаки на VPN-шлюз выглядит предсказуемо: сканирование периметра -> fingerprinting VPN-сервиса -> эксплуатация уязвимости аутентификации или brute force (T1110) -> установка VPN-сессии -> lateral movement -> ransomware. На пентесте задача - дойти до VPN-сессии и показать заказчику, что периметр пробит. Дальше - уже пост-эксплуатация.

Ошибка в логике валидации сертификатов Remote Access VPN и Mobile Access на шлюзах Check Point с Gaia OS при использовании IKEv1 позволяет неаутентифицированному удалённому атакующему установить VPN-соединение без валидного пароля. Без пароля. Просто зайти.

CVSS-вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N - атака по сети, низкая сложность, привилегии не нужны, действие пользователя не нужно, scope changed (выход за границы компонента), высокий импакт на конфиденциальность, низкий на целостность. CISA SSVC Decision - Act: active exploitation, automatable, total technical impact.

[Применимо: внешний пентест, legacy-инфраструктура с IKEv1, Check Point Gaia OS (затронутые версии - в advisory)]

Все четыре предусловия должны выполняться одновременно:

1. VPN Remote Access или Mobile Access включён на шлюзе
2. IKEv1 разрешён для Remote Access (протокол deprecated)
3. Шлюз принимает подключения от legacy Remote Access клиентов
4. Машинный сертификат для подключений не установлен как обязательный (Mandatory)

Если хотя бы одно условие не выполнено - шлюз не уязвим к CVE-2026-50751. Для отчёта это критически важно: нужно подтвердить наличие всех четырёх условий, а не просто обнаружить IKEv1 в ответе ike-scan. Я видел отчёты, где пентестер писал "IKEv1 detected -> vulnerable". Нет. Так не работает.

Параллельно Check Point раскрыл CVE-2026-50752 (CVSS 7.4, CWE-295 - Improper Certificate Validation) - слабость валидации сертификатов IKEv1 для site-to-site VPN, позволяющая MitM-атаку на туннель между площадками. CVSS-вектор: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N - обратите внимание на AC:H (высокая сложность) и отсутствие changed scope. На момент раскрытия эксплуатация CVE-2026-50752 в дикой природе не зафиксирована. EPSS - 0.0486 (top 10%), CISA SSVC Decision - Track.

По имеющимся публикациям, эксплуатация наблюдалась с мая 2026 года, попытки участились в начале июня. Детали инфраструктуры атакующих и предполагаемая параллельная эксплуатация VPN-уязвимостей других вендоров требуют независимой верификации по advisory соответствующих вендоров.

Пошаговая проверка Check Point VPN на уязвимости аутентификации​

[Применимо: внешний пентест (black box / grey box), Check Point Gaia OS]

Требования к окружению:

• Kali Linux или аналог (Parrot, BlackArch)
• ike-scan >= 1.9, nmap >= 7.80 с NSE-скриптами, nuclei >= 3.x
• RAM: 4 ГБ минимум
• Сетевой доступ к целевому IP: UDP 500, UDP 4500, TCP 443
• Актуальные шаблоны nuclei: nuclei -update-templates перед тестированием

Шаг 1. Fingerprinting VPN-сервиса. Определяем, что перед нами Check Point и какой протокол обмена ключами включён:

# IKE fingerprinting - определение вендора и версии протокола
ike-scan -M --showbackoff TARGET_IP
# Проверка IKE-сервиса - version detection (NSE-скрипт ike-version отсутствует в стандартной поставке Nmap)
nmap -sU -p 500,4500 -sV TARGET_IP

В выводе ike-scan ищем Vendor ID с идентификатором Check Point. Ответ на IKEv1 Main Mode означает, что IKEv1 включён - первое предусловие CVE-2026-50751 выполнено. Если UDP 500 молчит - проверяем TCP 443 на предмет Mobile Access portal: curl -skI https://TARGET_IP/sslvpn/ покажет характерные для Check Point заголовки.

Шаг 2. Проверка CVE-2026-50751. Публичный шаблон Nuclei в официальном репозитории ProjectDiscovery:

nuclei -t http/cves/2026/CVE-2026-50751.yaml -u https://TARGET_IP -timeout 10

Положительный результат требует ручной верификации - nuclei может давать false positive на кастомизированных порталах Mobile Access. Шаблон детектирует только косвенные HTTP-индикаторы (версия портала, баннеры), но НЕ проверяет фактическую эксплуатируемость IKEv1 bypass. CVE эксплуатируется через IKE на UDP 500, не через HTTP. Единственный способ подтвердить - ручная проверка конфигурации IKE через ike-scan + анализ настроек шлюза (grey/white box). False negative при нестандартной конфигурации - вполне реальный сценарий.

Шаг 3. Ручная верификация (grey box / white box). При доступе к SmartConsole проверяем конфигурацию напрямую:

• Security Gateway -> VPN Clients -> Authentication -> "Allow older clients to connect to this gateway""Разрешить старым клиентам подключаться к этому пути" должно быть снято
• VPN Community -> Encryption -> General -> Encryption Method: только IKEv2
• Security Gateway -> VPN Clients -> Authentication -> Machine Certificate Authentication: Mandatory

Если все три настройки в небезопасном состоянии - шлюз уязвим. В black box сценарии выводы строятся на результатах шагов 1-2 плюс косвенные признаки (принятие IKEv1 Main Mode, характерные Vendor ID).

Шаг 4. Проверка патча. Хотфиксы Check Point выпущены для затронутых версий Gaia OS (номера SK-статей и список версий - в официальном advisory для CVE-2026-50751). В grey box сценарии запрашиваем у заказчика версию Gaia OS и статус установки хотфикса. В black box - фиксируем наличие уязвимых условий и рекомендуем немедленный патч.

Когда техника НЕ работает:

• Сканирование IKE (UDP 500/4500) может быть заблокировано ISP или пограничным firewall - переключаемся на HTTP-проверку портала
• Публичного PoC для полной эксплуатации CVE-2026-50751 на момент написания нет - подтверждение строится на проверке конфигурации, не на получении VPN-сессии
• Если шлюз мигрирован на IKEv2 и legacy-клиенты отключены - CVE-2026-50751 неприменима, переходим к brute force (T1110.003 - Password Spraying) и проверке MFA

Пентест Fortinet SSL VPN​

Разведка FortiGate и типовые ошибки конфигурации​

[Применимо: внешний пентест, legacy и modern FortiOS]

Fortinet FortiGate - один из самых распространённых VPN-шлюзов на корпоративном периметре. По данным Check Point Research, та же группировка, эксплуатирующая CVE-2026-50751, предположительно атакует VPN-уязвимости Fortinet.

Fingerprinting. Fortinet SSL VPN имеет характерный веб-портал, обычно на https://target/remote/login или https://target:10443/remote/login. Вызов curl -skI https://TARGET/remote/login покажет специфичные cookie (например, SVPNCOOKIE), а nmap --script http-title -p 443,10443 TARGET отобразит заголовок "SSL-VPN Login" или "Please Login". На продакшн-шлюзах с кастомизированным логином заголовок может отличаться - тогда ищем HTML-маркеры fgt_lang или FortiToken в теле ответа.

Типовые векторы проверки:

1. Brute force учётных данных (T1110.003 - Password Spraying): Fortinet SSL VPN в ряде версий FortiOS не включает lockout по умолчанию - проверяйте конфигурацию. Серия из 5-10 попыток с заведомо неверным паролем покажет, настроен ли lockout. Отсутствие блокировки - находка уровня High для отчёта
2. Определение версии FortiOS: HTTP-заголовки, SNMP (при известном community string) или анализ JavaScript-файлов портала (/resource/javascript/jsconsole/) могут раскрыть точную версию. Дальше проверяем по базе CVE
3. SAML SSO misconfiguration: при интеграции с IdP (Azure AD, ADFS) перехватываем SAML-ассерции через Burp Suite - проверяем replay-атаки, подмену атрибутов, слабые подписи (SHA-1)

Когда техника НЕ работает:

• FortiGate с активной подпиской FortiGuard IPS режет автоматизированные сканеры по сигнатурам и поведению - ike-scan и nuclei могут быть отфильтрованы
• MFA через FortiToken делает brute force бесполезным: сразу переходим к проверке известных CVE для конкретной версии FortiOS
• Geo-IP фильтрация на уровне FortiGate может отбросить весь трафик от тестовой инфраструктуры - согласуем с заказчиком whitelist IP

Тестирование безопасности Cisco VPN​

AnyConnect, IKEv2 и SAML SSO - проверка VPN на уязвимости​

[Применимо: внешний пентест, Cisco ASA/FTD, legacy IKEv1 и modern IKEv2 + SAML]

У Cisco несколько VPN-решений: AnyConnect / Secure Client (SSL + IKEv2), legacy IPSec VPN на ASA и Catalyst SD-WAN. Каждое тестируется по-разному.

Fingerprinting AnyConnect. Веб-портал на TCP 443: curl -skI https://TARGET/ - в ответе ищем заголовок X-Transcend-Version или маркер webvpn в теле - признак ASA/FTD. Для проверки IKE: ike-scan -M TARGET_IP на UDP 500 - ответ подтверждает IKE-сервис.

Проверка SAML SSO. Cisco AnyConnect часто использует SAML для аутентификации через корпоративный IdP. Перехват SAML-ассерции в Burp Suite (запрос к /+CSCOE+/saml/sp/acs) позволяет проверить три параметра: время жизни ассерции (NotOnOrAfter - слишком длинное окно даёт возможность replay), алгоритм подписи (SHA-1 - слабость) и Audience Restriction (если ассерция принимается от произвольного IdP - критическая ошибка конфигурации).

Контекст CVE-2026-20245 (Cisco Catalyst SD-WAN Manager). CVE-2026-20245 (CVSS 7.8, CWE-116 - Improper Encoding or Escaping of Output, в CISA KEV) - локальная эскалация привилегий до root через crafted-файл в SD-WAN Manager (vManage). Уязвимость не в VPN-клиенте, а в управляющей платформе. В цепочке атаки это пост-эксплуатация: если VPN-сессия до SD-WAN контроллера получена, CVE-2026-20245 даёт root на управляющей платформе и возможность распространения конфигурационных изменений на edge-устройства. EPSS - 0.2532 (top 5%). SSVC Decision - Act, но Automatable=no (нужен локальный аутентифицированный доступ), что снижает приоритет относительно CVE-2026-50751 (Automatable=yes). На внутреннем пентесте с доступом к SD-WAN инфраструктуре - проверять обязательно.

Когда техника НЕ работает:

• ASA/FTD с Threat Detection блокирует ike-scan после первых пакетов - используйте медленный режим с задержками
• AnyConnect с DAP (Dynamic Access Policy) ограничивает возможности после аутентификации - успешный вход не равен полному доступу к сети
• Cisco ISE с Posture Assessment отбросит подключение из Kali без корпоративного агента - согласуйте тестовый профиль с заказчиком

Выбор вектора атаки на VPN: таблица решений​

Условие	Вендор	Вектор	Инструмент	Kill Chain
IKE на UDP 500 отвечает IKEv1	Check Point	CVE-2026-50751	ike-scan, nuclei	Initial Access (T1190)
SSL VPN портал на 443/10443	Fortinet	Brute force, CVE по версии	hydra, nuclei	Initial Access (T1190)
AnyConnect портал на 443	Cisco	SAML replay, password spray	Burp Suite	Credential Access (T1212)
IKEv1 + legacy clients	Check Point	CVE-2026-50751/50752	ike-scan, nuclei	Initial Access (T1190)
MFA отключено или только SMS	Любой	Password spray (T1110.003)	hydra, custom scripts	Credential Access
SD-WAN Manager доступен	Cisco	CVE-2026-20245 (локальный)	crafted file	Post-Exploitation
SAML SSO с SHA-1 подписью	Любой	SAML replay/forge	Burp Suite	Credential Access (T1212)

Логика выбора: UDP 500 - первая проверка. Если IKEv1 отвечает - приоритетный вектор через CVE. Только IKEv2 или SSL - переходим к анализу веб-портала и SAML. MFA с аппаратным токеном - brute force бесполезен, сосредотачиваемся на CVE для конкретной версии ПО.

Чеклист аудита VPN-безопасности​

Готовый чеклист для передачи заказчику или включения в отчёт по результатам пентеста VPN-инфраструктуры:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

CVE-2026-50751 - не технический прорыв. Это баг в deprecated-протоколе, который должен был быть отключён годы назад. IKEv1 официально deprecated, все три вендора об этом знают. Но на реальных пентестах я продолжаю находить IKEv1 включённым в production. Причины одни и те же: «"egacy-клиенты не поддерживают IKEv2", "перенастройка повлияет на L2L-туннели с партнёрами", "работает - не трогай".

Проблема не в конкретной CVE. Проблема в operational debt - накопленном долге по выведению из эксплуатации устаревших протоколов и конфигураций. IBM X-Force фиксирует 29 месяцев как среднее время до устранения CVE. Для deprecated-протоколов эта цифра стремится к бесконечности, потому что "отключить IKEv1" - не патч, а изменение архитектуры, которое проходит через три раунда согласований, тестирование совместимости и откладывается "до следующего квартала". Знакомо?

На каждом внешнем пентесте VPN-инфраструктуры первым делом проверяйте UDP 500. Если IKEv1 жив - дальше обычно вопрос конкретного CVE под версию. А в отчёте рекомендуйте не "установить патч", а "вывести из эксплуатации IKEv1 как класс протокола и провести ревизию всех legacy-зависимостей на периметре". Количество вещей, которые давно пора было выключить, говорит о зрелости ИБ больше, чем количество СЗИ в стойке.