TS Solution
TS Solution
Пользуясь нашим сайтом, вы соглашаетесь с тем, что мы используем cookies 🍪
Настройки cookie
Обязательные cookies
Эти файлы cookie необходимы для того, чтобы вы могли пользоваться сайтом и его функциями. Их нельзя отключить. Они устанавливаются в ответ на ваши запросы, такие как настройка ваших предпочтений конфиденциальности, вход в систему или заполнение форм.
Аналитические cookies
Disabled
Эти файлы cookie собирают информацию, чтобы помочь нам понять, как используются наши веб-сайты или насколько эффективны наши маркетинговые кампании, или чтобы помочь нам настроить наши веб-сайты для вас.
Рекламные cookies
Disabled
Эти файлы cookie предоставляют рекламным компаниям информацию о вашей активности в Интернете, чтобы помочь им предоставлять вам более релевантную онлайн-рекламу или ограничивать количество показов рекламы. Эта информация может быть передана другим рекламным компаниям.

Информация об уязвимости CVE-2024−24 919
Если вы работаете с NGFW Check Point — обратите внимание на эту статью.

Появилась новая информация об уязвимости CVE-2024-24919. Как оказалось, проблема гораздо серьёзнее, чем могло показаться ранее. По новой информации, уязвимости подвержены не только локальные учетные записи, но и блэйд Mobile Access (конкретно служба VPND).

Всем, у кого включен и используется блэйд Mobile Access, необходимо проделать следующие действия:

1. Поставить хотфикс. Его можно скачать в статье:
https://support.checkpoint.com/results/sk/sk182336
Также в этой статье есть подробная инструкция по установке со скриншотами. Обратите на это внимание.
2. Сбросьте пароли от всех локальных УЗ, которые подключаются к VPN с аутентификацией по паролю.
3. Запретить подключения к VPN всем локальным УЗ с аутентификацией по паролю.
4. Обновить на SG CA cертификат для Outbound SSL Inspection.
5. Обновить на SG серверный cертификат для Inbound SSL Inspection.
6. Обновить все пароли GAIA OS пользователей и от режима Expert.

Вместо п.1 можно просто отключить блэйд Mobile Access и удалить шлюз из Remote Access Community (это не отменяет выполнение всех остальных пунктов).
Также в качестве дополнительной меры мы настоятельно рекомендуем проверить, есть ли у вас Stealth правило, которое блокирует все соединения к шлюзам и SMS, кроме тех, которые явно разрешены в management правиле. Важно закрыть SSH и https соединения к шлюзам из недоверенных источников.
Каким образом проверить, уязвим ли ваш шлюз
Выполняем следующую команду:
curl -k -X POST https://Внешний ip шлюза/clients/MyCRL -H "Host: Внешний ip шлюза" -H "Content-Length: 38" -d "aCSHELL/../../../../../../../etc/hosts"

  • Если вы получили ответ 404 или тайм-аут → уязвимости нет.
  • Если выводится содержимое файла /etc/hosts → шлюз уязвим.

Также, вы можете проверить, были ли атаки на ваш шлюз
Стали известны ip адреса, с которых были атаки. Найти соответствующие события вы сможете в логах при условии, что у вас включено логирование Implied Rules.

Выполните в Smart Console в разделе logs amd monitor поисковый запрос по логам:
23.227.196.88 or 23.227.203.36 or 37.19.205.180 or 38.180.54.104 or 38.180.54.168 or 46.59.10.72 or 46.183.221.194 or 46.183.221.197 or 64.176.196.84 or 87.206.110.89 or 104.207.149.95 or 109.134.69.241 or 146.70.205.62 or 146.70.205.188 or 149.88.22.67 or 154.47.23.111 or 156.146.56.136 or 158.62.16.45 or 167.61.244.201 or 178.236.234.123 or 185.213.20.20 or 185.217.0.242 or 192.71.26.106 or 195.14.123.132 or 203.160.68.12 or 68.183.56.130 or 167.99.112.236 or 132.147.86.201 or 162.158.162.254
or 61.92.2.219 or 183.96.10.14 or 198.44.211.76 or 221.154.174.74 or 112.163.100.151 or 103.61.139.226 or 82.180.133.120 or 146.185.207.0/24 or 193.233.128.0/22 or 193.233.216.0/21 or 217.145.225.0/24 or 31.134.0.0/20 or 37.9.40.0/21 or 45.135.1.0/24 or 45.135.2.0/23 or 45.155.166.0/23 or 5.188.218.0/23 or 85.239.42.0/23 or 88.218.44.0/24 or 91.132.198.0/24 or 91.218.122.0/23 or 91.245.236.0/24

Важно понимать, что информацию с ваших шлюзов могли считать автоматически, используя ботов-роботов. Атака с помощью украденных данных/паролей может "докатиться" до вас и через полгода. Поэтому, если ваш шлюз был уязвим, важно обязательно выполнить действия, указанные выше.
Чтобы исключить риск ошибки, желательно выполнить резервное копирование текущего состояния шлюза, а также сервера управления, чтобы при возникновении проблем быстро «откатиться» на рабочую конфигурацию и минимизировать возможный простой.