Архив метки: PostgreSQL

В блоге компании Sysdig вышел пост о первой хорошо задокументированной агентной ransomware-кампании JADEPUFFER

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

В блоге компании Sysdig вышел пост о первой хорошо задокументированной агентной ransomware-кампании JADEPUFFER

В блоге компании Sysdig вышел пост о первой хорошо задокументированной агентной ransomware-кампании JADEPUFFER. Суть там в следующем. Первоначальный доступ злоумышленники получили через опубликованный в Интернет сервер Langflow (платформа для создания и развертывания AI-агентов и workflow), проэксплуатировав уязвимость CVE-2025-3248. Эта уязвимость позволяет удалённому неаутентифицированному атакующему с помощью специально сформированного HTTP-запроса выполнить на сервере произвольный код. Далее злоумышленники запустили адаптивную и полностью автоматизированную кампанию, дошли до целевой системы и пошифровали базу данных продакшена. 🤖🤷‍♂️ При компрометации базы эксплуатировалась уязвимость обхода аутентификации в Nacos (CVE-2021-29441). Nacos - платформа для динамического обнаружения сервисов, управления конфигурациями и администрирования сервисов.

Эксперты Sysdig приводят следующие аргументы в пользу того, что эти действия выполнялись полностью автоматически:

🔻 Все полезные нагрузки доставлялись через RCE-уязвимость в Langflow в виде Python-кода, закодированного в Base64. Декодированные полезные нагрузки содержат большое количество комментариев, объясняющих, почему выполняется каждое действие. Там есть приоритизация целей по "окупаемости" (Return on Investment), определение "самой крупной" базы данных и описание назначения каждого шага. Люди обычно не добавляют комментарии к каждой команде вида python3 -c, а LLM делают это по умолчанию.

🔻 Слишком быстрая диагностика и исправление ошибок. Например, за 30-50 секунд был пройден полный цикл от неудачной попытки входа до диагностики причины ошибки, исправления кода и успешной аутентификации.

🔻 Во время атаки LLM читала обычный текст, найденный в системе, и принимала решения на его основе, а не просто искала совпадения по шаблонам. Такое поведение повторялось даже в разных сессиях с интервалом в несколько недель.

Ну и более 600 осмысленных пейлоадов, выполненных за короткий промежуток времени… Не очень похоже на человека с фиксированным набором утилит. 😉

Мораль? Если не будете детектировать и устранять уязвимости, мисконфигурации и прочие экспозиции, то вас рано или поздно взломают и пошифруют. Это произойдёт с нечеловеческой скоростью и эффективностью и не потребует от злоумышленника особой квалификации. 👾👻

Читать далее →

Майский Linux Patch Wednesday

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

Майский Linux Patch Wednesday

Майский Linux Patch Wednesday. Всего 1638 уязвимостей (474 в ядре Linux). Для сравнения, в апреле было 1035 уязвимостей (рекорд!). А в этот раз получается снова рекорд и более чем в полтора раза больше! Ускорение впечатляет и пугает. Но посмотрим, что дальше будет. Где-то оно должно стабилизироваться. Хотя количество критичных уязвимостей уже такое, что все их рассмотреть становится весьма проблематично. Для 7 уязвимостей есть признаки эксплуатации вживую. А ещё для 264 есть публичные эксплойты. Начнём, как обычно, с эксплуатирующихся уязвимостей по данным CISA KEV и VulnCheck KEV. Здесь в топе, ожидаемо, два громких способа получить root shell:

🔻 EoP - Linux Kernel "Copy Fail" (CVE-2026-31431)
🔻 EoP - Linux Kernel "Dirty Frag" (CVE-2026-43500)

Остальные эксплуатирующиеся:

🔻 RCE - Apache ActiveMQ (CVE-2026-40466). Судя по описанию, это обход фикса для CVE-2026-34197, о которой я уже писал ранее.

🔻 AuthBypass - Rclone (CVE-2026-41176). Rclone ("rsync для облачных хранилищ") - это консольная утилита для синхронизации файлов и каталогов между различными облачными хранилищами и локальными системами. Эксплуатация уязвимости может привести к несанкционированному доступу к чувствительной административной функциональности, включая функции настройки и удалённого управления.

🔻 RCE - NGINX (CVE-2026-42945). Уязвимость позволяет без аутентификации выполнять код на сервере при использовании директив rewrite и set.

🔻 DoS - PgBouncer (CVE-2026-6664). PgBouncer - это компактный инструмент с открытым исходным кодом для пуллинга соединений с базами данных PostgreSQL. Он снижает накладные расходы на установку соединений, управляя пулом подключений к одному или нескольким серверам PostgreSQL, что повышает производительность и эффективность использования ресурсов в приложениях с частыми короткоживущими подключениями к базе данных. Целочисленное переполнение (integer overflow) в коде разбора сетевых пакетов в версиях PgBouncer до 1.25.2 позволяет обойти проверку границ (boundary check) и может привести к аварийному завершению процесса.

🔻 XSS - Postorius (CVE-2026-44742). Postorius - это веб-интерфейс на базе Django для работы с GNU Mailman. Mailman представляет собой свободное программное обеспечение для управления списками рассылки электронной почты, включая дискуссионные группы и новостные рассылки. Уязвимость эксплуатируется в атаках, согласно VulnCheck KEV, однако публичного эксплоита пока не видно.

Из остальных уязвимостей с эксплоитом, но пока без признаков эксплуатации в реальных атаках можно выделить:

🔸 RCE - Apache HTTP Server (CVE-2026-23918). Ошибка двойного освобождения памяти (double-free) в механизме очистки потоков модуля mod_http2 Apache httpd, приводящая к возможности удалённого выполнения кода без предварительной аутентификации (pre-auth RCE).

🔸 RCE - Apache Tomcat (CVE-2026-34486). Модуль кластерных коммуникаций Apache Tomcat Tribes некорректно обрабатывает ошибки расшифрования в EncryptInterceptor и не отбрасывает соответствующие сообщения, что позволяет неаутентифицированному атакующему выполнить произвольный код через механизм десериализации Java на порту 4000.

🔸 RCE - ProFTPD (CVE-2026-42167). Ошибка в обработке некоторых переменных журналирования (например, %U) модулем mod_sql позволяет неаутентифицированному атакующему выполнить SQL-инъекцию через команду USER.

🔸 EoP - Linux Kernel "DirtyDecrypt" (CVE-2026-31635). Локальная уязвимость повышения привилегий в Linux в цепочке расшифрования RxRPC/GSSAPI. Отсутствие проверки skb_cow_data() в rxgk_decrypt_skb() позволяет непривилегированному локальному атакующему перезаписывать в памяти (в page cache) содержимое файлов, доступных только для чтения.

🔸 EoP - Linux Kernel "Fragnesia" (CVE-2026-46300). Эту уязвимость я тоже уже разбирал ранее. Ошибка в skb_try_coalesce() позволяет осуществлять запись в page cache через фрагментированные ESP-пакеты.

🔸 EoP - Linux Kernel (CVE-2026-46333). Локальное повышение привилегий до root и раскрытие учётных данных в Linux Kernel ptrace Path, обнаруженное исследователями Qualys.

🔸 EoP - PackageKit "Pack2TheRoot" (CVE-2026-41651). PackageKit - это программный комплекс с открытым исходным кодом, предназначенный для предоставления унифицированного высокоуровневого слоя абстракции над различными системами управления пакетами. Уязвимость позволяет атакующему получить root-доступ и скомпрометировать систему.

🔸 ComInj - Composer (CVE-2026-40261, CVE-2026-40176). Composer - это менеджер зависимостей для PHP. Уязвимость присутствует в методе Perforce::generateP4Command(). Из-за недостаточной очистки параметров конфигурации репозитория (таких как url, p4user или client) при формировании shell-команд атакующий, контролирующий файл composer.json, может выполнить произвольные команды в системе жертвы при выполнении composer install или composer update.

🗒 Полный отчёт Vulristics

На прошлой неделе Дмитрий Черняков выложил на сайте АЛТЭКС-СОФТ интересную новость о возобновлении выпуска Windows-версий сканера уязвимостей RedCheck

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

На прошлой неделе Дмитрий Черняков выложил на сайте АЛТЭКС-СОФТ интересную новость о возобновлении выпуска Windows-версий сканера уязвимостей RedCheck

На прошлой неделе Дмитрий Черняков выложил на сайте АЛТЭКС-СОФТ интересную новость о возобновлении выпуска Windows-версий сканера уязвимостей RedCheck. Суть там в следующем: АЛТЭКС-СОФТ более трёх лет вкладывали все ресурсы в развитие Linux-версии RedCheck из опасения не вписаться в тренды импортозамещения. Приоритетом было не добавление новой функциональности, а миграция архитектуры продукта. Сначала продукт перевели на СУБД PostgreSQL. Затем на Linux, выбрав Astra Linux в качестве базового дистрибутива. В итоге в декабре 2023 года АЛТЭКС-СОФТ выпустили стабильную Linux-версию RedCheck 2.7.0 и стали выпускать новые версии (примерно раз в полгода) только под Linux. Казалось бы, успех: проект миграции на российскую ОС успешно выполнен, и дальше можно развивать только Linux-версию? А вот и нет.

Отследив активации лицензий и версии сканеров, в компании оценили, какие версии реально используют пользователи. Оказалось, что большинство до сих пор работает со старой Windows-версией. Причины могут быть разные: нехватка Linux-специалистов, боязнь нового, доступность "серого" ПО Microsoft или всё вместе. В итоге в АЛТЭКС-СОФТ признали: они переоценили темпы перехода на отечественные ОС, и Windows в России по-прежнему широко используется.

Было принято решение возобновить выпуск современной Windows-версии и перейти к кроссплатформенной кодовой базе. АЛТЭКС-СОФТ планируют это сделать с версии 2.14, которая выйдет осенью. Разработка потребует времени и ресурсов и повлияет на текущие планы, часть задач будет пересмотрена по срокам. Код для Linux-версии изначально создавался кроссплатформенным, тратить время на его перенос не потребуется. Придётся потратить время только на сборку и отладку под компонентную зависимость Windows. Есть основания полагать, что АЛТЭКС-СОФТ смогут это сделать достаточно быстро. Выходу RedCheck VM это повредить не должно, т.к. это технически независимый продукт, и над ним работает другая команда.

Из-за значительного технологического разрыва между версиями 2.6 и 2.14 бесшовное обновление Windows-версии будет невозможно. Придётся переходить либо через чистую установку с переносом хостов и групп через CSV, либо через поэтапную миграцию с промежуточными Linux-версиями с сохранением всех данных и конфигураций.

Чему может научить эта история?

🔹 Прежде чем принимать важные решения по изменению архитектуры, необходимо удостовериться, что конкретно ваши клиенты к этому готовы. Архитектурные изменения, вполне принимаемые и даже ожидаемые в Enterprise-сегменте, могут не приниматься сегментом SMB. Нужно знать своего клиента.

🔹 Как видим, половинчатая позиция государства по части импортозамещения ОС создаёт проблемы разработчикам отечественного ПО. Непонятно, насколько это импортозамещение всерьёз. Если всерьёз, то необходимо усиление регуляторного давления на бизнес (не только гос. сектор), чтобы использование продукции Microsoft было максимально неудобным, дорогим, рискованным, нерукопожатным. Ну, это если действительно есть заинтересованность в импортозамещении ОС. А если её нет, то не стоит удивляться, что российские бизнесы продолжат сидеть на ПО Microsoft (в надежде, что когда-нибудь всё будет как раньше 😏) и всю риторику по импортозамещению пропускать мимо ушей.

Августовский Linux Patch Wednesday

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

Августовский Linux Patch Wednesday

Августовский Linux Patch Wednesday. Я припозднился с этим LPW, т.к. улучшал генерацию списков LPW-бюллетеней и работу Vulristics. 🙂 В августе Linux вендоры начали устранять 867 уязвимостей, почти в 2 раза больше, чем в июле. Из них 455 в Linux Kernel. Для одной уязвимости есть признаки эксплуатации вживую (CISA KEV):

🔻 SFB - Chromium (CVE-2025-6558) - эксплуатируемая SFB в Chromium уже четвёртый месяц подряд. 🙄

Для 72 (❗️) уязвимостей доступны публичные эксплоиты или имеются признаки их существования. Можно выделить:

🔸 RCE - WordPress (CVE-2024-31211) - прошлогодняя, но в Debian пофиксили недавно; Kubernetes (CVE-2025-53547), NVIDIA Container Toolkit (CVE-2025-23266), Kafka (CVE-2025-27819)
🔸 Command Injection - Kubernetes (CVE-2024-7646)
🔸 Code Injection - PostgreSQL (CVE-2025-8714/8715), Kafka (CVE-2025-27817)
🔸 Arbitrary File Writing - 7-Zip (CVE-2025-55188)

🗒 Полный отчёт Vulristics

Мартовский выпуск "В тренде VM": уязвимости Microsoft, PAN-OS, СommuniGate и кто должен патчить хосты с развёрнутым прикладом

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

Мартовский выпуск "В тренде VM": уязвимости Microsoft, PAN-OS, СommuniGate и кто должен патчить хосты с развёрнутым прикладом.

📹 Ролик на VK Видео, RUTUBE, YouTube
🗞 Пост на Хабре
🗒 Дайджест на сайте PT

Содержание:

🔻 00:00 Вступление
🔻 00:41 Elevation of Privilege - Windows Ancillary Function Driver for WinSock (CVE-2025-21418)
🔻 01:22 Elevation of Privilege - Windows Storage (CVE-2025-21391)
🔻 02:04 Authentication Bypass - PAN-OS (CVE-2025-0108)
🔻 03:19 Remote Code Execution - CommuniGate Pro (BDU:2025-01331)
🔻 04:37 VM-ная загадка: кто должен патчить хосты с развёрнутым прикладом
🔻 07:21 Про дайджест трендовых уязвимостей

Кстати, продакшн нам делают ребята из brocast.team. Очень толковые и внимательные к деталям. 👍 Сложные приколюшечки типа 03:49 сами придумывают и реализуют. 😮 А склеечки какие аккуратненькие делают - ммм. Работать с ними одно удовольствие. 😇 Рекомендую!

Обновление хостов с прикладом: альтернативное мнение

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

Обновление хостов с прикладом: альтернативное мнение

Обновление хостов с прикладом: альтернативное мнение. Пришёл комментарий от подписчика к VM-ной задачке про 2 подразделения и обновление хостов с развёрнутыми приложениями. С любезного разрешения выкладываю текст полностью. 🙂

"Имея опыт работы с обоих сторон ("общей инфры" и админа приклада — как раз того самого Postgres), хотел бы заметить следующее. Всё же обновлением ОС должна заниматься команда, которая заведует ОС и обще-инфраструктурными сервисами, крутящимися на хостах. А админы прикладного ПО — должны следить за своим ПО.

Но все вместе они — должны согласовывать свои действия.

На хосте, помимо условного постгреса, может крутиться много всякого другого. О чём "прикладные админы" могут знать, но не факт, что могут этим грамотно управлять и правильно оценить последствия обновления пакетов. Пример навскидку — на хосте наверняка будут установлены агенты систем мониторинга — как ИТ-шного, так и ИБ-шного. И передать на админов условного постгреса ответственность за обновление хоста со всем этим набором… А "прикладники" точно должны этим заниматься? 😊 Тогда как мимо линуксовых админов установка, настройка и эксплуатация всех этих дополнительных сервисов на хостах с прикладом точно не пройдёт.

По опыту банка, в котором я работал — хосты обновляли линуксовые админы, а "прикладные" — только тот приклад, который в их зоне ответственности. Пакеты, относящиеся к прикладу, ставились на hold сразу при установке приклада, и их обновление было невозможно при обновлении хоста.

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

У такой схемы, безусловно, есть свои преимущества. И она весьма удобна админам, т.к. они занимаются профильными задачками, а непонятной им фигнёй не заморачиваются. Но вот VM-щику такая совместная работа и размытие ответственности невыгодны, т.к. ему придётся частенько "тыкать палочкой" две (а возможно и более) команды, которые будут показывать друг на друга. 😑 Критичные уязвимости не будут устраняться с формулировкой "обновление отложено". А кто будет нести ответственность в случае, если уязвимость будет проэксплуатирована в течение этого "отложенного" периода непонятно. Видимо предполагается, что нести ответственность будет сам VM-щик. 😏 Так что VM-щикам топить за такую схему я бы не советовал.

Но если в организации такая схема устоялась и успешно работает, то рушить её, естественно, тоже не следует. Следует аккуратненько описывать регламенты решения спорных вопросов, чтобы всегда был однозначный крайний, на которого будет направлен пушинг. Ну и кары в случае инцидента.

В любом случае, главное, чтобы обновления ставились и уязвимости устранялись (желательно с соблюдением SLA). А как именно это происходит и чьими силами не так уж важно. 😉