У тебя был хороший перерыв? Была ли у вас возможность вздохнуть? Проснуться.
На дворе 2025 год, а хаос продолжается.
Хаха, видишь, что мы сделали? Мы написали то же самое в 2024 году, потому что 2024 год был точно таким же.
Как отрасль, мы переживаем день сурка, но давайте назовем его Годом сурка и представим, что это не просто невероятно удручает.
Однако, как по маслу, у нас есть уязвимости в Ivanti Connect Secure, которые имеют все признаки APT, использующего нулевой день для критически важного устройства.
Сходство и сходство с проблемами и драмой, которые распространяли продукцию Ivanti в январе 2024 года, откровенно говоря, невероятно, и мы надеялись, что Ivanti извлекут уроки из этого опыта в отношении эффективного реагирования.
Мы имеем в виду, что они подписали обещание и получили потрясающую возможность сфотографироваться, и мы не верим, что любая компания, производящая технику, основной целью которой является своего рода функция безопасности, могла бы подписать необязывающее обязательство со стороны своей армии. корпоративных юристов для развлечения.
К счастью, это позволяет использовать такие изображения, как:
На этот раз, справедливости ради, пользователям Ivanti Connect Secure патч доступен немного раньше (для тех, у кого травмирующие воспоминания о прошлогодней саге об исправлениях — хватит читать здесь), но еще раз — пользователям других затронутых устройств, таких как Ivanti's Policy Secure и Нейроны шлюзов ZTA ждут патча до 21 января 2025 года.
То же упражнение — у нас есть активная эксплуатация, по-видимому, со стороны одного и того же злоумышленника — но технические подробности самой уязвимости на местах малоизвестны. Что-то о том, чтобы гарантировать, что злоумышленники, которые уже используют уязвимость, не смогут воспроизвести ее и продолжать использовать? Спилберг действительно гордился бы уровнем театра, который мы, как индустрия, иногда переживаем.
Редактор: По многим причинам здесь неточно отражен объем работы, усилий и чистого таланта, который регулярно вкладывается в наши исследования. Умение проявляется не в том, насколько сложной и запутанной можно сделать тему при ее объяснении, а в том, насколько понятным и доступным можно пройти процесс или тему.
Все, что мы знаем из рекомендаций, это то, что версии Ivanti Connect Secure
Повреждение памяти в 2025 году, что дальше? Очевидно, это затронуло и некоторые другие случайные продукты Ivanti, что, конечно, абсолютно шокирует.

Выделяется CVE-2025-0282 — предварительная аутентификация, RCE. Мы готовим.

Дайте нам добычу
С помощью магии, искусства заключения сделок и просто Интернета мы быстро получили исправленную версию 22.7R2.5 (для краткости называемую R2.5) и предыдущую версию 22.7R2.4 (для краткости называемую R2.4). ).
Наши ранее задокументированные //bin/bash
обход больше не работает (забавно, потому что мы видели, как он появился в половине Интернета после публикации), поэтому мы сделали что-то еще, что позволило нам проверить содержимое корневой файловой системы как обычно (Иванти, пожалуйста, сосредоточьтесь на более важных вещах).
Мы дифференцировали всю корневую файловую систему. groupA-home
в наших системах — и поначалу были перегружены множеством мелких изменений. Однако многие из них оказались неважными — например, каждый CGI-файл Perl имел номер версии в комментарии вверху файла, из-за чего наивные инструменты определяли его как обновленный файл. Несколько быстрых sed
команды позже, однако, и они были удалены, оставив нам кучу двоичных файлов.
Однако почти все они имели одинаковый размер до и после исправления и снова содержали лишь незначительные изменения, такие как обновления строки версии. Заметным исключением из этого правила был файл с именем root\\home\\bin\\web
который увеличился в исправленной версии примерно на 4 КБ.
Беглый просмотр файла показал, что это скомпилированный двоичный файл, написанный на C++, поэтому мы запустили Diaphora, инструмент для обнаружения изменений в скомпилированных двоичных файлах, и запустили его.
Как всегда, все не происходит мгновенно — нам действительно пришлось подождать несколько минут, чтобы выполнить это сравнение, которое примерно в 20 раз превышает длину нашего любимого видео в TikTok, и поэтому, пока нам было скучно, мы решили запустить strings
против двух двоичных файлов (исправленного и неисправленного).
В выводе видно лишь несколько изменений, и, как всегда, большинство из них — мусор, но мы заметили дымящийся пистолет:
--- r2.4\\groupA-home\\root\\home\\bin\\web.strings
+++ r2.5\\groupA-home\\root\\home\\bin\\web.strings
Client Connection Instance not present. Can't Pause Input from %s user session, svcId : %d
Client Connection Instance not present. Can't Resume Input from %s user session, svcId : %d
+Client IP value exceeds %d size limit
Client Session Type: %d, Real Host detail not present
Client TCP Source port is %d
+Client capabilities exceeds %d size limit
Client cert is not required
Client certificate required, verify mode=[%d] .
+Client hostname exceeds %d size limit
Client wants %d
Вы видите то, что мы видим? Ряд новых сообщений об ошибках, сообщающих нам, что значения «превышают предел размера». Для нас это звучит как-то слишком. Может ли это быть связано с одним из переполнений стека, за которым мы следим?
В любом случае, вернемся к TikTok, пока мы ждали завершения Diaphora, прежде чем погрузиться в выяснение того, действительно ли это были подсказки.
К счастью, код содержит изрядное количество отладочных строк, и мы заметили встроенную строку Too late for IFT_PREAUTH_INIT
.
Это 2l8, b4by.
Это многообещающе — это предполагает, хотя и в некоторой степени, что мы находимся в коде, который выполняется до аутентификации, — и это дает нам ценную подсказку относительно того, в какой части кодовой базы мы находимся.
Хотя сложные методы исследования (Google) не дают нам результатов для постоянного IFT_PREAUTH_INIT
мы вскоре узнали, что IFT
(вернее, IF-T
) — это открытый стандарт совместимости VPN. Также известный как IFTTLS, он работает через TLS, предоставляя альтернативный способ подключения к VPN.
Благодаря руководству Mandiant по воспроизведению этой уязвимости мы видим, что злоумышленники удаляют файл журнала, относящийся к IF-T
— дополнительные материалы, подтверждающие наши подозрения, что это CVE-2025-0282.

Наши сердца упали — значит ли это, что нам теперь придется установить больше программного обеспечения, а именно VPN-клиент Ivanti, чтобы разобраться в этом? К счастью, из-за IF-T
поскольку это открытый стандарт, нам не пришлось этого делать, поскольку этот протокол поддерживается OpenConnect, VPN-клиентом с открытым исходным кодом.
Чтение комментариев OpenConnect к протоколу наполняет нас чувством страха:
Некоторые Pulse VPN могут запрос сертификат клиента, но не на самом деле требовать один. Если вы пытаетесь пройти аутентификацию в такой VPN и сталкиваетесь со странными ошибками, связанными с нераспознанными типами пакетов, то имитация очень старый версия официального клиентского программного обеспечения Pulse может помочь решить проблему:

Это… возможно, это худший «запах кода», с которым мы когда-либо сталкивались.
ЕСЛИ-Т[his then hax]
Давайте притворимся, что мы этого не заметили, потому что злоумышленник, вероятно, также не видел этот открытый исходный код, свободно доступный в Интернете, и вместо этого притворимся исследователями безопасности, сфокусированными на лазере, которыми мы стремимся быть (а не ох-смотрите — блестящая штука, перескакивающая из одного проекта в другой, хакеры, которыми мы на самом деле являемся).
Вернувшись в комнату, вернемся к IF-T
.
Как вы помните, исправленная версия прошивки Ivanti Connect Secure принесла с собой новое сообщение об ошибке, предупреждающее о «чрезмерных возможностях клиента». Ну давай же…..
Поиск «возможностей» в клиенте OpenConnect не дает ничего особенно полезного, поэтому это должно быть что-то, что OpenConnect не поддерживает (но наш эксплойт поддерживает).
К счастью, pulse.c
файл, который обрабатывает IF-T
довольно легко расширить. Совершенно очевидно, как IF-T
пакет создан — вот отрывок:
buf_append_ift_hdr(reqbuf, VENDOR_JUNIPER, 0x88);
buf_append(reqbuf, "clientHostName=%s", vpninfo->localname);
bytes = ;
if (bytes[0])
buf_append(reqbuf, " clientIp=%s", bytes);
buf_append(reqbuf, "\\n%c", 0);
ret = send_ift_packet(vpninfo, reqbuf);
Мы видим, что пакет основан на ASCII и имеет несколько пар ключ-значение, где ключ и значение разделены символом. =
. Мы также можем видеть, что в пакете имеется несколько пар, разделенных пробелом (здесь clientHostName
и clientIp
).
Стоит ли нам попробовать добавить clientCapabilities
ключ с очень длинным значением и посмотрите, что произойдет?
Подыграйте дома – как вы думаете, нам стоит?
Добавим немного озорства pulse.c
файл и перестроить.

if (bytes[0])
buf_append(reqbuf, " clientIp=%s", bytes);
+ buf_append(reqbuf, " clientCapabilities=%s", bytes);
+ for(unsigned int n=0; n
Что происходит с устройством Ivanti Connect Secure, предназначенным для обеспечения безопасности?

Сэр, я хотел бы вернуть деньги.
Действительно, взглянув на код, мы обнаруживаем чья-то неприятную маленькую оплошность (для краткости мы сильно отредактировали этот фрагмент):
char dest[256];
clientCapabilities = getKey(req, "clientCapabilities");
if ( clientCapabilities != NULL )
{
clientCapabilitiesLength = strlen(clientCapabilities);
if ( clientCapabilitiesLength != 0 )
connInfo->clientCapabilities = clientCapabilities;
}
}
memset(dest, 0, sizeof(dest));
strncpy(dest, connInfo->clientCapabilities, clientCapabilitiesLength);
Уф! Разработчик (справедливо) использовал strncpy
вместо небезопасного strcpy
но ошибочно передал размер входной строки — нет размер буфера назначения — как ограничение размера.
Это означает, что если злоумышленник отправит clientCapabilities
блок размером более 256 байт, они перейдут в другие переменные стека (опущены выше для ясности) и, в конечном итоге, в адрес возврата, где ожидает RCE.
Эксплуатация несколько «осложнена» двумя факторами:
- Во-первых, включены средства защиты ASLR и PIE (это означает, что трудно определить, какие адреса переполнять буфер).
- Во-вторых, после вызова функции происходит ряд других вызовов функций (не показанных выше).
strncpy
которые зависят от состояния других переменных стека, которые неизбежно повреждаются, поэтому любой эксплойт должен быть осторожным, чтобы избежать сбоя.
Во избежание сомнений, ботаники, мы решили, что пришло время посоветоваться. Как всегда, мы смотрели на членов команды Tower, которые давали нам постоянные советы, — на наших собак.
«Должны ли мы выпустить эксплойт для этой новой уязвимости, чтобы защитники оказались на одном игровом поле с злоумышленниками, учитывая, что она уже используется в реальных условиях?»
«Нет, это абсолютно безумие. Представьте себе, что сказали бы ботаники в ответах в Твиттере по поводу вооружения преступников, которые уже вооружены: давайте держать все в секрете и жить в мире тайн».
Ну, вот и все. Наши собачьи консультанты посоветовали нам пока воздержаться от генератора артефактов обнаружения. Может быть, через неделю (таймер запускается сейчас, идти).
Краткое содержание
Что ж, похоже, это настоящая сделка — законное переполнение буфера стека предварительной аутентификации, присутствующее в конфигурации по умолчанию.
Предусмотрены меры по предотвращению эксплойтов, и это приятно (читай: «все немного менее плохо, чем могло бы быть»). Вероятно, это немного замедлило использование APT-группами этой уязвимости, но, очевидно, не предотвратило ее и сегодня неактуально.

Мы рады, что ситуация улучшилась после обещания Ivanti «Безопасность посредством дизайна». Мы также отмечаем, что мы рассмотрели только одну из двух уязвимостей — более серьезную (интересную), неаутентифицированную уязвимость.
Мы призываем всех отнестись к этому серьезно. Выбросьте свои соглашения об уровне обслуживания уязвимостей на ветер в подобных ситуациях, они больше не актуальны, и разница между быстрым ответом и ответом в часах может быть разницей в том, позвонит ли ваша организация вашему киберстраховщику или нет.
Хотя мы быстро указываем на уязвимость и устраняем ее, мы постарались внести свой вклад, в том числе снова поработать с The Shadowserver Foundation, чтобы поделиться механизмом, который мы используем в нашей клиентской базе для безопасного выявления уязвимых устройств. Мы считаем, что это позволит фонду начать уведомлять сертификаторов, которые затем смогут поговорить со своими коллегами, чтобы продвигать исправления.
В watchTowr мы искренне верим, что будущее за непрерывным тестированием безопасности и что быстрое реагирование на возникающие угрозы в одиночку предотвращает неизбежные нарушения.
С помощью платформы watchTowr мы предоставляем эту возможность нашим клиентам каждый день. Наша задача — точно понять, как возникающие угрозы, уязвимости и TTP могут повлиять на их организации.
Если вы хотите узнать больше о Платформа WatchTowrнаше решение по управлению поверхностью атак и непрерывному автоматизированному Red Teaming, пожалуйста, свяжитесь с нами.