Уязвимость на одном из серверов Касперского
-
Похожий контент
-
Автор cringemachine
Коллеги, доброго.
Надо перенести несколько устройств с одного вирт. сервера на другой вирт. сервер.
Создаю задачу Смена сервера администрирования. Может кто уже сталкивался - в каком формате указывать адрес нового сервера (см. скриншот)?
Подозреваю, что должно быть что-то вроде «<IP-адрес главного сервера>/<Наименование виртуального сервера>"».
-
Автор KL FC Bot
Исследователи обнаружили три уязвимости в популярной платформе для контент-менеджмента Sitecore Experience Platform:
CVE-2025-34509 заключается в наличии жестко заданного в коде пароля (причем состоящего из одной буквы), позволяющего атакующему удаленно аутентифицироваться в служебной учетной записи; CVE-2025-34510 — уязвимость типа Zip Slip, позволяющая аутентифицированному пользователю загрузить ZIP-архив и распаковать его в корневую папку сайта; CVE-2025-34511 также позволяет загрузить на сайт посторонний файл, но на этот раз вообще произвольный. Используя первую уязвимость совместно с любой из остальных двух, атакующий может удаленно добиться выполнения произвольного кода (RCE) на сервере под управлением Sitecore Experience Platform.
На данный момент нет свидетельств об использовании этих уязвимостей в реальных атаках, однако опубликованный экспертами из watchTowr Labs анализ содержит достаточно подробностей для создания эксплойта, так что злоумышленники могут взять их на вооружение в любой момент.
View the full article
-
Автор KL FC Bot
14 ноября компания Google выпустила бюллетень, в котором сообщила о серьезной уязвимости в ряде процессоров компании Intel, начиная с поколения Ice Lake, выпущенного в 2019 году. Потенциально, эта уязвимость может приводить к отказу в обслуживании, эскалации привилегий или раскрытию чувствительной информации. На момент подготовки статьи обновления микрокода, закрывающие проблему, были выпущены для 12-го и 13-го поколений процессоров Intel (соответственно, Alder Lake и Raptor Lake). Патчи для процессоров 10-го и 11-го поколений (Ice Lake и Tiger Lake) готовятся. Полный список подверженных процессоров представлен на сайте Intel в виде огромной таблицы.
По словам представителей Intel, о нестандартном поведении процессоров инженеры компании знали, но проблема считалась некритичной, и ее решение отложили на первую половину 2024 года. Но ситуация изменилась, когда исследователи из компании Google, независимо от Intel, обнаружили проблему. Собственно, все детали уязвимости мы знаем от специалистов Google, а конкретно из статьи Тависа Орманди.
Фаззинг процессоров
Тавис Орманди имеет на своем счету множество обнаружений серьезных уязвимостей в различных программах и устройствах. Совсем недавно мы писали о его предыдущем исследовании, в ходе которого была обнаружена уязвимость Zenbleed в процессорах AMD. Тогда Тавис говорил о развитии применения фаззинга для поиска аппаратных проблем.
Фаззинг — это метод, который подразумевает подачу случайной информации на ввод тестируемой информационной системы. Как правило, ее применяют для автоматизированного поиска уязвимостей в софте: создается специальная «оснастка», позволяющая взаимодействовать с программой и отслеживать ее состояние. Дальше происходят десятки и сотни тысяч тестов, в ходе которых можно обнаружить нестандартное поведение тестируемого кода.
В случае испытания процессоров все несколько сложнее. Мы должны генерировать случайные программы, которые при этом работают без собственных сбоев, и выполнять их на процессоре. Как в таком случае отделить штатное поведение процессора от аномального? Ведь далеко не всегда ошибка в процессе выполнения ПО приводит к сбою. Орманди предложил методику, в рамках которой одинаковый «случайный» код одновременно выполняется на разных процессорах. По идее, результат работы одной и той же программы должен быть одинаковый, а вот если результат отличается, то возможно это признак проблемы. Именно такой подход выявил проблему в процессорах Intel.
Посмотреть статью полностью
-
Автор KL FC Bot
В последнее время на новостных сайтах, связанных с тематикой информационной безопасности, часто упоминалась система управления контентом (CMS) WordPress. Чаще всего причиной были уязвимости во всевозможных плагинах и темах для нее; впрочем, наши коллеги также наблюдали кейс, в котором злоумышленники распространяли трояны через плохо защищенные WordPress-сайты. Само по себе это не удивительно — данная CMS остается одной из самых популярных. Но такое количество обнаруженных в ее плагинах уязвимостей и связанных с ней инцидентов говорит о том, что за ней тщательно следят не только исследователи из мира ИБ, но и злоумышленники.
Инциденты, связанные с WordPress
Только за это лето стало известно о нескольких достаточно серьезных инцидентах, в которых злоумышленники действовали через WordPress.
Плагин Gravity Forms: компрометация сайта и заражение кода
В начале июля злоумышленники получили доступ к сайту Gravity Forms, популярного расширения для создания форм, и внедрили вредоносный код в версии 2.9.11.1 и 2.9.12 плагина. Сайты, на которых эти версии плагина были установлены администраторами вручную или через инструмент управления PHP-зависимостями Composer в период с 9 по 10 июля, были заражены зловредом.
Зловред блокировал дальнейшие попытки обновления пакета, скачивал и устанавливал дополнительный вредоносный код и добавлял учетные записи с правами администратора. В результате злоумышленники получали возможность захватить сайт и использовать его для какой-либо вредоносной активности.
Разработчики Gravity Forms рекомендуют всем своим пользователям проверить, не установлена ли у них потенциально опасная версия. Инструкции, как это легко сделать, можно найти в предупреждении об инциденте на официальном сайте плагина. Там же находится и инструкция по устранению угрозы. Ну и, разумеется, необходимо обновить плагин до версии 2.9.13.
View the full article
-
Автор ВладиславFox
Звиняюсь за форму подачи информации (это был запрос в поддержку, помощи по которому я жду уже второй день, а сроки горят)
Если кто то ставил уже ksmg не как отдельную систему (физическую или логическую), а интегрированно в сам почтовый сервер физический/логический (одна и та же ос, без виртуалок, гипервизоров и тд) прошу подсказать.
Не видит постфикс на шаге интеграции с почтовым сервером
предлогает только ручную интеграцию (которая не описана в инструкции)
Пункт инструкции:
Если Postfix отсутствует в списке доступных почтовых серверов для интеграции, но при этом он установлен на сервере, необходимо вернуть конфигурационный файл /etc/postfix/master.cf в исходное состояние и повторно запустить скрипт первоначальной настройки.
Проблема в том что мы не изменяли конфигурационный файл.
(напоминание ос Debian 12, почтовое решение Iredmail, postfix, dovecoat, sogo, nginx, clamav -шли одним установочным комплектом. Требуется чтоб антивирусное решение Касперсокого (KMSG) стояло на том же сервере, в той же системе и защищало почту)
Выполненые шаги скрипта установки:
Select web server [1]:
[1] Nginx
[2] Abort setup
> 1
Setup will use the following web server configuration:
| type: Nginx
| config_dir: /etc/nginx
| config_file: nginx.conf
| systemd_name: nginx
| binary_name: /usr/sbin/nginx
| sites_dir: /etc/nginx/conf.d
| user: www-data
Continue setup using this configuration? [1]:
[1] Continue setup
[2] Abort setup
> 1
Specify IP address of the current node
The IP address will be used to communicate with other nodes [10.10.0.10]:
>
Specify the port number of the current node
The port number will be used to communicate with other nodes [9045]:
>
Specify the port number of the current node for web interface
The port number will be used to access KSMG web interface [443]:
>
Port 443 is already in use.
Specify the port number of the current node for web interface
The port number will be used to access KSMG web interface [443]:
> 445
Select MTA [1]:
[1] Manual integration
Note that by selecting "Manual integration", you will skip automatic integration with an MTA, so you will have to change the MTA configuration files manually.
> 1
при запуске всех служб ksmg отключаются все системы удаленного управления cockpit/webmin, так и должно быть ?
но прописанный в скрипте установке порт веб интерфейса ksmg (в нашем случае 445) ничего не выводит ни удаленно, ни с самого сервера.
среди ошибок есть что то про лицензию (как и куда прописать код нашей лицензии)
и все та же проблема что пр установке скрипт, не видит почтового сервера(ПО) postfix, только мануальная интеграция. как говорил ранее мы не меняли конфиг постфикса, он изначально шел комплектом с кучей других пакетов (и они уже интегрированы друг в друга).
напомню нашу ситуацию
у нас всего один сервер и одна ос (никаких вирутальных машин, гипервизоров, кластеров)
и почтовый сервер и ksmg должны стоять на одном и том же сервере и в одной и той же ос.
setup-250415-102638.log traceback-250415-105029.txt master.txt
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти