D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Источник: https://labs.watchtowr.com/check-point-wrong-check-point-cve-2024-24919/
Перевёл: BLUA специально для xss.is
Собирайтесь, собирайтесь - настало время очередного поста в блоге, в котором мы вскрываем устройство SSLVPN и раскрываем недавно эксплуатируемую уязвимость из реальной среды. На этот раз объектом нашего пристального внимания является Check Point.
Check Point, для тех, кто не в курсе, является поставщиком, ответственным за устройство под названием CloudGuard Network Security, еще одно устройство, заявляющее о своей безопасности и защищенности. Их слоган — "вы заслуживаете лучшей безопасности" — подразумевает уровень защиты, на который можно положиться в их продуктах.
Мы решили заглянуть внутрь их устройства, и недавно у нас появилась отличная возможность это сделать в виде уязвимости CVE-2024-24919. Это уязвимость с приоритетом "высокий", которая (согласно самому CVE) попадает в категорию "разглашение конфиденциальной информации неавторизованному лицу". Check Point сообщает, что уязвимость активно эксплуатируется, и дает следующее резюме (среди других рекомендаций):
Уязвимость потенциально позволяет злоумышленнику считывать определенную информацию на шлюзах, если они подключены к Интернету и включены с использованием удаленного доступа через VPN или мобильного доступа.
Здесь нет определенного класса уязвимости, только очень расплывчатое и неопределенное описание. Мы задались вопросом, что именно подразумевается под "определенной информацией" в этом контексте — означает ли это, что можно считать токены сессий? Или конфигурацию устройства? Хеши паролей? (спойлер: на самом деле всё гораздо хуже). В Интернете не было много информации об этой уязвимости, поэтому мы решили разобраться, насколько всё плохо, чтобы поделиться деталями с администраторами устройств, которым нужно принять важное решение — устанавливать исправление или нет.
Время анализа патча
Эта уязвимость кажется отличным кандидатом для анализа патча, при котором уязвимая и исправленная системы сравниваются, чтобы выявить детали самого патча, а следовательно, и уязвимости.
Как всегда, первым препятствием в этом является получение исправленной версии программного обеспечения. Хотя патчи, указанные в рекомендациях, находятся за формой входа, мы обнаружили, что само устройство загружает патчи без каких-либо учетных данных, поэтому мы установили патч и задокументировали полученные файлы, чтобы сравнить каждый файл с его версией до установки патча.
Нам не пришлось так стараться, так как, исследуя файловую систему устройства, мы вскоре обнаружили файл .tgz, содержащий сам обновленный пакет, внутри временной директории. Отлично! Открыв его, мы нашли кучу скучных установочных скриптов и многообещающий файл с названием sslvpn.full, представляющий собой ELF-бинарник. По крайней мере, в этот раз нам не придется пялиться на утомляющий PHP-код — это бинарный файл, так что мы можем насладиться дизассемблированием под x86. Прекрасно.
Код: Скопировать в буфер обмена
Мы должным образом загрузили уязвимую и исправленную версии файла в IDA и использовали Diaphora, чтобы выявить различия. Сразу же нам бросилось в глаза кое-что (уязвимый код слева, исправленный справа):
Хмм, интересно — был добавлен новый код, который логирует строку "Suspected path traversal attack from". Похоже, можно с уверенностью предположить, что ошибка связана с атакой обхода путей.
Копаясь в коде, мы видим, что была добавлена новая функция логирования с именем
Это здорово — мы всего несколько минут занимаемся анализом, и уже обнаружили несколько важных зацепок! Во-первых, мы почти уверены, что ищем уязвимость обхода пути, а во-вторых, у нас есть сильное подозрение, что она затрагивает конечную точку
Небольшое расследование показывает, что этот конечный пункт предназначен для обслуживания статических файлов из определённого местоположения на файловой системе. Файлы могут быть указаны через сам URI в формате
Попытки добавить элементы обхода пути, такие как
Код: Скопировать в буфер обмена
Безуспешно! Как же нам разобраться в том, что происходит, и выйти за рамки слепых догадок? Конечно, взглянув на ту большую функцию
Понимание декомпилированного кода
Большая обработчика функция может показаться пугающей, но на самом деле она довольно простая. Переключившись на уязвимую версию кода, мы можем быстро заметить, что она выполняет ввод-вывод файлов, на что указывают явные ссылки на функции
Немного сложно понять, что делает код, из-за необычного способа обращения к строковым ресурсам, которые IDA не распознаёт. Взгляните на следующий фрагмент кода:
Что здесь происходит? Код сравнивает что-то (URL, который запросил пользователь) с рядом жестко закодированных строк, расположенных в таблице строк. IDA не знает, где находится эта таблица строк, но GDB может показать нам это во время выполнения — оказывается, она находится здесь:
Точно! Ошибка не является чем-то сложным или запутанным, она кроется в использовании функции
Ну, оказывается, мы не можем. Мы можем передавать такие пути, как
Вот очень похожий фрагмент кода, который находится сразу под первым. Снова мы перебираем таблицу строк и сравниваем с запрашиваемым URL. Опять же, мы запускаем GDB и смотрим на таблицу строк, которую он использует:
Коротко, но емко. Мы были очень взволнованы, когда увидели эту запись — можете догадаться, почему?
Да, точно! Из-за слэша в конце строки. Это указывает на то, что эта запись — не файл, а директория, что означает, что мы можем пройти внутрь неё, а затем выйти обратно через известную команду
Что ж, мы попробовали и, затаив дыхание, отправили следующий запрос:
Код: Скопировать в буфер обмена
Нам воздалось содержимым запрашиваемого файла.
Код: Скопировать в буфер обмена
Вот оно! Траверс пути, который приводит к произвольному чтению файла! Поскольку нам удалось прочитать такой важный файл, как файл теневых паролей, это означает, что мы выполняемся с привилегиями суперпользователя и можем читать любой файл в файловой системе по нашему выбору.
Подожди, что?!
На этом этапе мы были несколько озадачены. То, что мы обнаружили, — это возможность произвольного чтения файлов, которая позволяет читать любой файл в системе. Это гораздо более мощная уязвимость, чем подразумевается в уведомлении поставщика.
Мы поспешили установить патч на наш сервер и убедиться, что действительно обнаружили CVE-2024-24919, а не какую-то другую уязвимость, и были немного удивлены, что да, это действительно CVE-2024-24919, и да, это уязвимость произвольного чтения файлов.
Интересно, что поставщик утверждает, что проблема затрагивает только устройства, на которых включена аутентификация по имени пользователя и паролю, а не (гораздо более сильная) аутентификация по сертификату. Изучив код, мы не видим очевидных причин для такого ограничения и задаемся вопросом, может ли пользователь с действительным сертификатом воспользоваться этой уязвимостью, даже когда аутентификация по паролю отключена.
Нас также несколько позабавили рекомендации поставщика по устранению уязвимости, среди которых выделяется вот этот совет:
Очевидные грамматические ошибки опустим, но совет разместить ваше защищённое пограничное устройство за другим защищённым пограничным устройством нас рассмешил.
Выводы
Этот баг было не слишком сложно найти, и он оказался чрезвычайно лёгким для эксплуатации, как только мы его обнаружили (полная эксплуатация оставлена в качестве упражнения для читателя — мы не хотим лишать вас всего удовольствия от работы с багом).
Мы немного обеспокоены заявлением поставщика — кажется, что оно преуменьшает серьёзность этого бага. Поскольку этот баг уже используется в реальных атаках злоумышленниками, кажется опасным рассматривать его как что-то меньшее, чем полноценную неавторизованную удалённую эксплуатацию (RCE). Администраторам устройств следует как можно быстрее обновить системы. Они заявляют:
Это довольно запутанное заявление, учитывая, что подключение к Интернету не является обязательным. Слова «получить доступ к информации» здесь выполняют серьёзную функцию, хотя, возможно, они и технически корректны в самом педантичном смысле этого выражения, но они умаляют то, что на самом деле является очень серьёзным багом, который следует рассматривать как «катастрофический» (по крайней мере, для тех администраторов, у которых нет второго устройства Check Point для защиты их основного устройства Check Point).
Поставщик, компания Check Point, выпустила «хотфикс» для данного бага, который рекомендуется установить администраторам, если они подверглись воздействию (для подробностей обратитесь к уведомлению поставщика).
В компании watchTowr мы считаем, что непрерывное тестирование безопасности — это будущее, которое позволит быстро выявлять комплексные уязвимости с высоким уровнем воздействия, затрагивающие вашу организацию.
Наша задача — понимать, как новые угрозы, уязвимости и тактики, техники и процедуры (TTPs) влияют на вашу организацию.
Если вы хотите узнать больше о платформе watchTowr, нашем решении для управления поверхностью атаки и непрерывного автоматизированного тестирования с использованием методов Red Team, пожалуйста, свяжитесь с нами.
Перевёл: BLUA специально для xss.is
Собирайтесь, собирайтесь - настало время очередного поста в блоге, в котором мы вскрываем устройство SSLVPN и раскрываем недавно эксплуатируемую уязвимость из реальной среды. На этот раз объектом нашего пристального внимания является Check Point.
Check Point, для тех, кто не в курсе, является поставщиком, ответственным за устройство под названием CloudGuard Network Security, еще одно устройство, заявляющее о своей безопасности и защищенности. Их слоган — "вы заслуживаете лучшей безопасности" — подразумевает уровень защиты, на который можно положиться в их продуктах.
Мы решили заглянуть внутрь их устройства, и недавно у нас появилась отличная возможность это сделать в виде уязвимости CVE-2024-24919. Это уязвимость с приоритетом "высокий", которая (согласно самому CVE) попадает в категорию "разглашение конфиденциальной информации неавторизованному лицу". Check Point сообщает, что уязвимость активно эксплуатируется, и дает следующее резюме (среди других рекомендаций):
Уязвимость потенциально позволяет злоумышленнику считывать определенную информацию на шлюзах, если они подключены к Интернету и включены с использованием удаленного доступа через VPN или мобильного доступа.
Здесь нет определенного класса уязвимости, только очень расплывчатое и неопределенное описание. Мы задались вопросом, что именно подразумевается под "определенной информацией" в этом контексте — означает ли это, что можно считать токены сессий? Или конфигурацию устройства? Хеши паролей? (спойлер: на самом деле всё гораздо хуже). В Интернете не было много информации об этой уязвимости, поэтому мы решили разобраться, насколько всё плохо, чтобы поделиться деталями с администраторами устройств, которым нужно принять важное решение — устанавливать исправление или нет.
Время анализа патча
Эта уязвимость кажется отличным кандидатом для анализа патча, при котором уязвимая и исправленная системы сравниваются, чтобы выявить детали самого патча, а следовательно, и уязвимости.
Как всегда, первым препятствием в этом является получение исправленной версии программного обеспечения. Хотя патчи, указанные в рекомендациях, находятся за формой входа, мы обнаружили, что само устройство загружает патчи без каких-либо учетных данных, поэтому мы установили патч и задокументировали полученные файлы, чтобы сравнить каждый файл с его версией до установки патча.
Нам не пришлось так стараться, так как, исследуя файловую систему устройства, мы вскоре обнаружили файл .tgz, содержащий сам обновленный пакет, внутри временной директории. Отлично! Открыв его, мы нашли кучу скучных установочных скриптов и многообещающий файл с названием sslvpn.full, представляющий собой ELF-бинарник. По крайней мере, в этот раз нам не придется пялиться на утомляющий PHP-код — это бинарный файл, так что мы можем насладиться дизассемблированием под x86. Прекрасно.
Код: Скопировать в буфер обмена
Код:
$ find -exec file {} \\;
...
./CheckPoint#fw1#All#6.0#5#1#HOTFIX_R80_40_JHF_T211_BLOCK_PORTAL_MAIN/fw1/bin/vpn.full: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, BuildID[sha1]=9484c3b95be69aa112042766793877d466fe9626, strippedМы должным образом загрузили уязвимую и исправленную версии файла в IDA и использовали Diaphora, чтобы выявить различия. Сразу же нам бросилось в глаза кое-что (уязвимый код слева, исправленный справа):
Хмм, интересно — был добавлен новый код, который логирует строку "Suspected path traversal attack from". Похоже, можно с уверенностью предположить, что ошибка связана с атакой обхода путей.
Копаясь в коде, мы видим, что была добавлена новая функция логирования с именем
send_path_traversal_alert_log. Если копнуть чуть глубже, мы также обнаружим новую функцию sanitize_filename, которая вызывает эту функцию логирования. Если посмотреть, что ссылается на саму sanitize_filename, мы увидим единственный вызов — большую функцию с автоматически сгенерированным именем sub_80F09E0. Если снова поискать ссылки на эту большую функцию, наше упорство вознаграждается: мы находим, что она передаётся в функцию cpHttpSvc_register_query вместе с HTTP-путём /clients/MyCRL, что сильно намекает на то, что это обработчик для данного конечного пункта.Это здорово — мы всего несколько минут занимаемся анализом, и уже обнаружили несколько важных зацепок! Во-первых, мы почти уверены, что ищем уязвимость обхода пути, а во-вторых, у нас есть сильное подозрение, что она затрагивает конечную точку
/clients/MyCRL.Небольшое расследование показывает, что этот конечный пункт предназначен для обслуживания статических файлов из определённого местоположения на файловой системе. Файлы могут быть указаны через сам URI в формате
/clients/MyCRL/file_to_get или через тело запроса POST. Мы провели несколько экспериментов с этим и обнаружили интересные, но бесполезные странности в работе сервера — добавление определённых управляющих символов в URL (например, /clients/MyCRL/test%0Atest) приводило к зависанию запроса, и обработка ошибок, связанных с экранированными байтами NULL, также казалась сомнительной, поскольку части кода, обслуживающего запросы, выполнялись, несмотря на серьёзные предупреждения, генерируемые в логе. Однако ничего из того, что мы попробовали в пути URL, не приводило к результатам, похожим на управляемое чтение файлов.Попытки добавить элементы обхода пути, такие как
.. в URL, не принесли результата, так как веб-сервер обрабатывал их правильно — но как насчёт тела POST-запроса? Оно не подпадает под обработку путей веб-сервером. Мы попробовали добавить стандартный полезный нагрузочный элемент ../../etc/passwd, но вскоре нас постигло разочарование, так как всё, что мы получили, это жалкий 404. Логи сервера показали, что устройство действительно отказывалось обслуживать наш путь:Код: Скопировать в буфер обмена
[vpnd 29382 4082644928]@i-022337f52dc65ca35[30 May 3:02:00][slim] http_get_CCC_callback: Invalid filename: /opt/CPsuite-R80.40/fw1//../../etc/passwdБезуспешно! Как же нам разобраться в том, что происходит, и выйти за рамки слепых догадок? Конечно, взглянув на ту большую функцию
sub_80F09E0!Понимание декомпилированного кода
Большая обработчика функция может показаться пугающей, но на самом деле она довольно простая. Переключившись на уязвимую версию кода, мы можем быстро заметить, что она выполняет ввод-вывод файлов, на что указывают явные ссылки на функции
_fopen и _fread — здесь, без сомнения, и находится наша ошибка. Но что именно она делает?Немного сложно понять, что делает код, из-за необычного способа обращения к строковым ресурсам, которые IDA не распознаёт. Взгляните на следующий фрагмент кода:
Что здесь происходит? Код сравнивает что-то (URL, который запросил пользователь) с рядом жестко закодированных строк, расположенных в таблице строк. IDA не знает, где находится эта таблица строк, но GDB может показать нам это во время выполнения — оказывается, она находится здесь:
Точно! Ошибка не является чем-то сложным или запутанным, она кроется в использовании функции
strstr разработчиком. Как известно гуру C, эта функция не сравнивает две строки напрямую, а ищет одну строку в другой. Это сразу заставило нас задуматься — можем ли мы злоупотребить этим небрежным сравнением, просто запросив относительный путь, который включает одну из строк из таблицы? Пока одна из строк присутствует внутри пути, проверка пройдет, и файл будет обслужен.Ну, оказывается, мы не можем. Мы можем передавать такие пути, как
icsweb.cab/../../etc/passwd, но операционная система не так глупа и не сможет найти файл, пожаловавшись на то, что icsweb.cab — это файл, а не каталог. Мы близки, я почти чувствую это! Давайте продолжим изучать этот код.Вот очень похожий фрагмент кода, который находится сразу под первым. Снова мы перебираем таблицу строк и сравниваем с запрашиваемым URL. Опять же, мы запускаем GDB и смотрим на таблицу строк, которую он использует:
Коротко, но емко. Мы были очень взволнованы, когда увидели эту запись — можете догадаться, почему?
Да, точно! Из-за слэша в конце строки. Это указывает на то, что эта запись — не файл, а директория, что означает, что мы можем пройти внутрь неё, а затем выйти обратно через известную команду
... Пока у нас есть строка CSHELL/ где-то в запрашиваемом файле, запрос будет принят, верно?Что ж, мы попробовали и, затаив дыхание, отправили следующий запрос:
Код: Скопировать в буфер обмена
Код:
POST /clients/MyCRL HTTP/1.1
Host: <redacted>
Content-Length: 39
aCSHELL/../../../../../../../etc/shadowНам воздалось содержимым запрашиваемого файла.
Код: Скопировать в буфер обмена
Код:
HTTP/1.0 200 OK
Date: Thu, 30 May 2024 01:38:29 GMT
Server: Check Point SVN foundation
Content-Type: text/html
X-UA-Compatible: IE=EmulateIE7
Connection: close
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Length: 505
admin:$6$rounds=10000$N2We3dls$xVq34E9omWI6CJfTXf.4tO51T8Y1zy2K9MzJ9zv.jOjD9wNxG7TBlQ65j992Ovs.jDo1V9zmPzbct5PiR5aJm0:19872:0:99999:8:::
monitor:*:19872:0:99999:8:::
root:*:19872:0:99999:7:::
nobody:*:19872:0:99999:7:::
postfix:*:19872:0:99999:7:::
rpm:!!:19872:0:99999:7:::
shutdown:*:19872:0:99999:7:::
pcap:!!:19872:0:99999:7:::
halt:*:19872:0:99999:7:::
cp_postgres:*:19872:0:99999:7:::
cpep_user:*:19872:0:99999:7:::
vcsa:!!:19872:0:99999:7:::
_nonlocl:*:19872:0:99999:7:::
sshd:*:19872:0:99999:7:::Вот оно! Траверс пути, который приводит к произвольному чтению файла! Поскольку нам удалось прочитать такой важный файл, как файл теневых паролей, это означает, что мы выполняемся с привилегиями суперпользователя и можем читать любой файл в файловой системе по нашему выбору.
Подожди, что?!
На этом этапе мы были несколько озадачены. То, что мы обнаружили, — это возможность произвольного чтения файлов, которая позволяет читать любой файл в системе. Это гораздо более мощная уязвимость, чем подразумевается в уведомлении поставщика.
Мы поспешили установить патч на наш сервер и убедиться, что действительно обнаружили CVE-2024-24919, а не какую-то другую уязвимость, и были немного удивлены, что да, это действительно CVE-2024-24919, и да, это уязвимость произвольного чтения файлов.
Интересно, что поставщик утверждает, что проблема затрагивает только устройства, на которых включена аутентификация по имени пользователя и паролю, а не (гораздо более сильная) аутентификация по сертификату. Изучив код, мы не видим очевидных причин для такого ограничения и задаемся вопросом, может ли пользователь с действительным сертификатом воспользоваться этой уязвимостью, даже когда аутентификация по паролю отключена.
Нас также несколько позабавили рекомендации поставщика по устранению уязвимости, среди которых выделяется вот этот совет:
Очевидные грамматические ошибки опустим, но совет разместить ваше защищённое пограничное устройство за другим защищённым пограничным устройством нас рассмешил.
Выводы
Этот баг было не слишком сложно найти, и он оказался чрезвычайно лёгким для эксплуатации, как только мы его обнаружили (полная эксплуатация оставлена в качестве упражнения для читателя — мы не хотим лишать вас всего удовольствия от работы с багом).
Мы немного обеспокоены заявлением поставщика — кажется, что оно преуменьшает серьёзность этого бага. Поскольку этот баг уже используется в реальных атаках злоумышленниками, кажется опасным рассматривать его как что-то меньшее, чем полноценную неавторизованную удалённую эксплуатацию (RCE). Администраторам устройств следует как можно быстрее обновить системы. Они заявляют:
Это довольно запутанное заявление, учитывая, что подключение к Интернету не является обязательным. Слова «получить доступ к информации» здесь выполняют серьёзную функцию, хотя, возможно, они и технически корректны в самом педантичном смысле этого выражения, но они умаляют то, что на самом деле является очень серьёзным багом, который следует рассматривать как «катастрофический» (по крайней мере, для тех администраторов, у которых нет второго устройства Check Point для защиты их основного устройства Check Point).
Поставщик, компания Check Point, выпустила «хотфикс» для данного бага, который рекомендуется установить администраторам, если они подверглись воздействию (для подробностей обратитесь к уведомлению поставщика).
В компании watchTowr мы считаем, что непрерывное тестирование безопасности — это будущее, которое позволит быстро выявлять комплексные уязвимости с высоким уровнем воздействия, затрагивающие вашу организацию.
Наша задача — понимать, как новые угрозы, уязвимости и тактики, техники и процедуры (TTPs) влияют на вашу организацию.
Если вы хотите узнать больше о платформе watchTowr, нашем решении для управления поверхностью атаки и непрерывного автоматизированного тестирования с использованием методов Red Team, пожалуйста, свяжитесь с нами.