Обзор уязвимости CVE-2024-24919 в NGFW Check Point и необходимые действия

28 мая 2024 года была обнаружена проблема в шлюзах безопасности Check Point с IPSec VPN в Remote Access VPN Community и программном обеспечении мобильного доступа blade.

В этом обзоре мы поделимся шагами по проверке шлюза и устранению CVE-2024-24919. Если у вас возникнут сложности с их выполнением – обратитесь на почту help@cpsupport.ru, инженеры поддержки оперативно ответят с экспертной обратной связью.

Суть этой уязвимости состоит в фиксации специальной рабочей группой Check Point попыток получения несанкционированного доступа к продуктам VPN, которые используются клиентами разработчика. Данная уязвимость может привести к открытию доступа к конфиденциальной информации на шлюзе безопасности.

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

Далее будут перечисляться инструкции по устранению уязвимости и проверке ваших шлюзов безопасности.

Если вы работаете с NGFW Check Point и у вас включен и используется блэйд Mobile Access, то рекомендуется проделать следующие действия:

• Поставить хотфикс. Его можно скачать в статье. Также в этой статье есть подробная инструкция по установке со скриншотами. Обратите на это отдельное внимание;
• Сбросьте пароли от всех локальных УЗ, которые подключаются к VPN с аутентификацией по паролю;
• Запретить подключения к VPN всем локальным УЗ с аутентификацией по паролю;
• Обновить на SG CA сертификат для Outbound SSL Inspection;
• Обновить на SG серверный сертификат для Inbound SSL Inspection;
• Обновить все пароли 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

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

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

Мы также хотим напомнить, что действенным методом защиты своих учётных записей является использование 2FA. Если вы ещё не используете 2FA — вы можете связаться с нами по почте sales@tssolution.ru, и мы расскажем о продуктах, способных обеспечить такую защиту.