Архивы автора: Alexander Leonov

Об авторе Alexander Leonov

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно прочитать здесь. Приглашаю подписаться на мой канал в Telegram @avleonovrus. Я обновляю его чаще, чем этот сайт. Вы можете обсудить мои посты или задать вопросы в @avleonovchat или в группе ВКонтакте. And I invite all English-speaking people to another telegram channel @avleonovcom.

Критическая уязвимость Remote Code Execution - PHP на Windows хостах (CVE-2024-4577) с публичным эксплоитом

2 комментария

Критическая уязвимость Remote Code Execution - PHP на Windows хостах (CVE-2024-4577) с публичным эксплоитом

Критическая уязвимость Remote Code Execution - PHP на Windows хостах (CVE-2024-4577) с публичным эксплоитом. CVSS 9.8. 6 июня разработчики PHP выпустили обновление для устранения RCE-уязвимости, которая связана с функцией преобразования кодировки Best-Fit в операционной системе Windows. Уязвимость позволяет неаутентифицированному злоумышленнику, выполняющему argument injection атаку, обойти защиту от старой активно эксплуатируемой RCE-уязвимости CVE-2012-1823 с помощью определенных последовательностей символов и выполнить произвольный код. Эксплоиты для уязвимости уже доступны на GitHub. Shadowserver Foundation отмечает активные сканирования, направленные на обнаружения уязвимых хостов. 👾

Уязвимость затрагивает все версии PHP, установленные в операционной системе Windows.

🔻 PHP 8.3 8.3.8
🔻 PHP 8.2 8.2.20
🔻 PHP 8.1 8.1.29 Версии PHP 8.0, PHP 7 и PHP 5 также уязвимы, но они уже в End-of-Life и не поддерживаются. 🤷‍♂️ Отдельно подчеркивается, что все инсталляции XAMPP также уязвимы по умолчанию. XAMPP - это популярная кроссплатформенная сборка локального веб-сервера, содержащая Apache, MariaDB, PHP, Perl и большое количество дополнительных библиотек. В случае, если обновление до актуальной версии PHP невозможно, исследователи из компании DEVCORE предлагают конфигурации для противодействия эксплуатации уязвимости. Однако эти рекомендации касаются инсталляций на Windows с определенными языковыми локалями (Traditional Chinese, Simplified Chinese, Japanese), для которых эксплуатация уязвимости была подтверждена. На других локалях из-за широкого спектра сценариев использования PHP в настоящее время невозможно полностью перечислить и исключить все потенциальные сценарии эксплуатации уязвимости. Поэтому пользователям рекомендуется провести комплексную оценку активов, проверить сценарии использования PHP и обновить PHP до последней версии.

Ездили сегодня с участниками PHDшной дискуссии в гости к ФСТЭК

Добавить комментарий

Ездили сегодня с участниками PHDшной дискуссии в гости к ФСТЭК

Ездили сегодня с участниками PHDшной дискуссии в гости к ФСТЭК. Обсуждали наши предложения по улучшению БДУ (24 пункта совместно насобирали). Впечатления от 3 часов обсуждения самые приятные. 👍 Очень обстоятельно и конструктивно по пунктам прошлись. Особенно большие надежды возлагаю на улучшение формализации данных по уязвимым версиям ПО, чтобы можно было в некоторой перспективе делать что-то вроде CPE-детектов. Свою ОСОКу, к сожалению, я пока не продал. 🤷‍♂️😅

Режим там строгий, так что без фоток. Иллюстрирую общедоступным скриншотом из Яндекс-панорам. 🙂

Думаю о том, что пора бы уже обновить карту отечественных вендоров Средств Управления Уязвимостями (СУУ)

Добавить комментарий

Думаю о том, что пора бы уже обновить карту отечественных вендоров Средств Управления Уязвимостями (СУУ)

Думаю о том, что пора бы уже обновить карту отечественных вендоров Средств Управления Уязвимостями (СУУ). Какие изменения напрашиваются с прошлого года:

🔹 В R-Vision VM теперь есть свои детекты уязвимостей. Значит следует добавить это решение и в категорию СДУИ.

🔹 Также в СДУИ стоит добавить SolidLab VMS.

🔹 Логотип Фродекс стоит заменить на VulnsIO для большей информативности, т.к. в основном у них этот бренд используется для VM-а.

Если есть какие-то идеи по изменениям в карте (чего-то добавить, чего-то убрать, поменять описание и т.д.), пишите, пожалуйста, в личку. 🙂

Основная фича грядущего июньского релиза MaxPatrol VM 2.5 - новый сканер веб-приложений

1 комментарий

Основная фича грядущего июньского релиза MaxPatrol VM 2.5 - новый сканер веб-приложений

Основная фича грядущего июньского релиза MaxPatrol VM 2.5 - новый сканер веб-приложений. И здесь речь не только о детектах для известных CVE уязвимостей, например, для Confluence или GitLab, которые, безусловно, очень важны для любого VM-продукта, о чём я уже писал ранее. Речь о полноценном DAST-сканере уязвимостей, с такой же функциональностью как в решениях PT BlackBox и PT AI.

Вообще вопрос о месте DAST-сканирования WEB-приложений дискуссионный. Этим нужно заниматься в рамках инфраструктурного VM-а или в рамках процессов AppSec-а? Рассмотрим аргументы.

Аргументы за AppSec:

🔻 Таргеты различаются. DAST-ом обычно сканят собственные разработки, а не чужие (коммерческие и опенсурсные) продукты. Если собственная разработка, значит AppSec.
🔻 Таски на исправление найденных уязвимостей летят в разработчиков, а не в админов. Опять же, разработка = AppSec.
🔻 Если же сканировались чужие продукты и при этом были найдены уязвимости, то по-хорошему нужно довести эту инфу до вендора и не попасть при этом под какие-нибудь юридические ограничения (анализ приложения может быть запрещён в лицензионном соглашении). Эти активности также более привычны AppSec-ам.
🔻 Одного DAST-а для полноценного анализа приложений всё равно не хватит, нужен SAST, IAST. Давайте не будем заниматься ерундой и будем анализировать приложения полноценно в рамках процессов AppSec.

Аргументы за инфраструктурный VM:

🔹 Вот сканируем мы хост и видим там веб-сервис (нашу разработку или не нашу - не суть важно). Почему бы не проверить его на ту же XSS-ку? Как-то глупо ограничивать себя только детектом CVE-шных уязвимостей. Тем более, что AppSec-и могут этот веб-сервис своими процессами вообще не покрывать, а мы может что-то массовыми сканами и продетектим.
🔹 Вот выстроили мы в рамках инфраструктурного VM-а процесс по поиску и исправлению известных уязвимостей. Почему бы не переиспользовать его и для web-уязвимостей? И там уязвимости, и там уязвимости. Удобно ведь будет работать со всеми уязвимостями в рамках одной единой системы, разве нет? 😏

В общем, есть аргументы у обеих сторон. В реальных организациях скорее это зависит от развития AppSec и VM отделов, кто кого подомнёт. 🙂 Моё мнение, что сканить веб-приложения DAST-ом должны и AppSec-и, и инфраструктурные VM-щики. Хуже не будет. А база для хранения продетектированных уязвимостей должна быть у них, в идеале, единой.

Но как бы ни выглядел итоговый процесс, его можно будет реализовать с помощью продуктов Positive Technologies. 😉

➡️ Более подробно о фичах нового MaxPatrol VM 2.5, включая сканирование веб-приложений, можно будет узнать на вебинаре 13 июня в 14:00. Регистрируйтесь!

3 года общего режима за нейтрализацию средств защиты компьютерной информации ЗОКИИ

Добавить комментарий

3 года общего режима за нейтрализацию средств защиты компьютерной информации ЗОКИИ

3 года общего режима за нейтрализацию средств защиты компьютерной информации ЗОКИИ. Частенько сталкиваюсь с позицией людей неИБшников, что обход требований и средств ИБ в организации это, в целом, нормальная практика и ничего зазорного в этом нет. Если есть права администратора на десктопе, то чего бы, допустим, не грохнуть агент DLP или EDR? А то ж работать мешает. 😏 Раз ИБшники активно не воспрепятствовали такому, значит они сами и виноваты.

В связи с этим в новостях пролетело интересное уголовное дело. Инженеру предприятия ВПК дали реальные 3 года общего режима по 274.1 УК РФ "Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации".

Цитата того, что он сделал:

"Установлено, что инженер, находясь по месту работы, имея умысел на копирование с целью дальнейшей модификации информации о ходе технологического процесса изготовления изделий на предприятии, нейтрализовал средство защиты компьютерной информации программно-технического комплекса, являющегося значимым объектом критической информационной инфраструктуры РФ"

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

Нафантазировать себе можно, например, следующее. В некоторой организации с некоторыми файлами можно работать только на некоторых десктопах. Копирование файлов с этих десктопов на флешку блокируются СЗИ. А некоторому инженеру очень нужно было скопировать и отредактировать какой-то файл на другом десктопе. Возможно, что никакой зловредной цели у него при этом не было. Возможно, что он наоборот всей душой радел за общее дело и хотел как лучше. Где-то что-то почитал про то, как и чем блокируется копирование на флешку, как это обходить. Поэкспериментировал - получилось, скопировал! Возможно даже сам похвастался кому-то на радостях. И заверте… 😱

Мораль? Не нарушайте требований ИБ в организации. Даже если глубоко презирайте ИБшников и считаете, что всё что они делают - мешают вам выполнять настоящую важную работу. Даже если вам неудобно. Неудобно? Жалуйтесь начальству! В крайнем случае увольняйтесь. Но никогда и ни в коем случае не делайте что-то втихаря. Это может очень плохо закончиться лично для вас. Особенно, если имеете дело с КИИ и ЗОКИИ.

Если у вас есть такие умники-нигилисты в знакомых, пошарьте им этот кейс. Возможно убережёте от беды.

Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) добавили в CISA KEV

3 комментария

Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) добавили в CISA KEV

Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) добавили в CISA KEV. Сама уязвимость относительно старая, январская. Я уже писал про неё в марте, когда вышел write-up и публичный эксплоит.

Несмотря на тривиальную эксплуатацию, запустил утилиту - получил рута, до недавнего времени признаков активной эксплуатации этой уязвимости не фиксировали. Что довольно странно, такой полезный эксплоит должен сразу попадать в инструментарий злоумышленников. Тут либо практическая эксплуатация всё же чем-то осложнена, либо использующие её злоумышленники не оставляли следов. 🤔

Как бы то ни было, 30 мая уязвимость добавили в CISA KEV, а значит факт использования её в атаках всё-таки был установлен. Но подробностей по атакам пока нет. Обратите внимание на эту уязвимость при обновлении Linux хостов.

Поздравляю бывших коллег с долгожданным ребрендингом! 🎉

Добавить комментарий

Поздравляю бывших коллег с долгожданным ребрендингом! 🎉

Поздравляю бывших коллег с долгожданным ребрендингом! 🎉 Больше двух лет история длилась.

Я, правда, поначалу предполагал, что имя сократят до "Тин". Так бы сохранилось неофициальное "Тинёк". Кроме того, т.к. "tin" это "жестяная банка", то получилась бы забавная игра слов. 🙂

Но Т - тоже хорошо. 💛

PS: Если Райффайзен всё-таки ребрендируют в R Банк, получится иронично. 😅