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

ТОП 5 CVE, которые чаще других эксплуатировались пентестерами Positive Technologies в 2023 году

ТОП 5 CVE, которые чаще других эксплуатировались пентестерами Positive Technologies в 2023 году. Отчёт вышел 2 июля.

Список уязвимостей:

🔻 Remote Code Execution - Microsoft Exchange "ProxyNotShell" (CVE-2022-41040, CVE-2022-41080, CVE-2022-41082)
🔻 Remote Code Execution - Bitrix Site Manager "PollsVotes" (CVE-2022-27228)
🔻 Elevation of Privilege - Polkit "PwnKit" (CVE-2021-4034)

Дальше в рифмованном виде. 😉 Трек сгенерировал в Suno.

---

По пентестам за прошедший год отчёт
Вышел у Позитивов.
Каждый кто его прочтёт,
Увидит, что там всё красиво.
28 проектов, есть что показать.
Статистика и результаты.
Умеют защищать и умеют ломать -
Молодцы ребята!
(Молодцы ребята!)

К отчёту они подошли всерьёз.
Ознакомьтесь без спешки!
Но у меня всегда один вопрос:
Где там CVE-шки?
(Где там CVE-шки?)

По отчёту уязвимости не сложно сосчитать.
Их совсем немного. Их конкретно пять.

Топ пять критичных уязвимостей.
Эксплуатируют их чаще всего в ходе пентестов.
Ужас пробирает до костей,
Когда видишь их в инфре: им не должно быть места!
Давно известны они все,
И что опасны они никто не возразит:
PollsVotes в Битриксе,
ProxyNotShell в Эксчендже,
А на Linux-ах PwnKit.

Самый популярный почтовый сервак
MS Exchange - лакомая цель любых атак.
3 уязвимости ProxyNotShell - по сути одна
Remote Code Execution. Опасность наглядно видна.

Bitrix Site Manager - популярная в России CMS.
И к тому же отечественная. Импортозамeс!
RCE в модуле "Опросы, голосования" -
Причина массовых дефейсов и для атак на инфру основание.

Ну а если злоумышленник
На Linux хост проник
И там спокойно сидит,
Нет надёжнее стратегии,
Чем поднять до root-a привилегии
Через уязвимость Polkit, PwnKit.

Топ пять критичных уязвимостей.
Эксплуатируют их чаще всего в ходе пентестов.
Ужас пробирает до костей,
Когда видишь их в инфре: им не должно быть места!
Давно известны они все,
И что опасны они никто не возразит:
PollsVotes в Битриксе,
ProxyNotShell в Эксчендже,
А на Linux-ах PwnKit.

Это были результаты за 2023 год.
Что за тренды нам текущий год принесёт?
Кто подаст надёжный патчиться сигнал?
Подпишись на @avleonovrus "Управление Уязвимостями и прочее", Telegram канал.

MP3 файл

Трендовые уязвимости июня по версии Positive Technologies

Трендовые уязвимости июня по версии Positive Technologies. Традиционно в 3 форматах:

📹 Рубрика "В тренде VM" в новостном ролике SecLab-а (начинается с 15:03)
🗞 Пост на Хабре, фактически это несколько расширенный сценарий рубрики "В тренде VM"
🗒 Компактный дайджест с техническими деталями на официальном сайте PT

Список уязвимостей:

🔻 EoP в Microsoft Windows CSC (CVE-2024-26229)
🔻 EoP в Microsoft Windows Error Reporting (CVE-2024-26169)
🔻 EoP в Microsoft Windows Kernel (CVE-2024-30088)
🔻 RCE в PHP (CVE-2024-4577)
🔻 EoP в Linux Kernel (CVE-2024-1086)
🔻 InfDisclosure в Check Point Security Gateways (CVE-2024-24919)
🔻 RCE в VMware vCenter (CVE-2024-37079, CVE-2024-37080)
🔻 AuthBypass в Veeam Backup & Replication (CVE-2024-29849)

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics. Общее количество уязвимостей снизилось с 1053 до 1040. Видимо для них стали доступны более ранние таймстемпы фиксов. Но уязвимости с признаком эксплуатации вживую и с публичным эксплоитом это не зацепило, они остались теми же.

🗒 Отчёт Vulristics по июньскому Linux Patch Wednesday

Linux Patch Wednesday: вот где этот майский пик!

Linux Patch Wednesday: вот где этот майский пик!

Linux Patch Wednesday: вот где этот майский пик! 🤦‍♂️ Также об июньском Linux Patch Wednesday. Помните, я в посте про майский Linux Patch Wednesday радовался, что, несмотря на введение правила по Unknown датам, пик в мае был незначительный. Хотя "32 406 oval definition-ов без даты получили номинальную дату 2024-05-15". Оказалось пик не был виден из-за ошибки в коде. Ба-дум-тсс! 🥸🤷‍♂️

То, что не все CVE-шки у меня попадаются в LPW бюллетени, несмотря на введение номинальных дат, я заметил на примере громкой уязвимости Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086), которой действительно нигде не было. Подебажил функцию распределения по бюллетеням, добавил тесты. Добился того, что все 38 362 CVE-шки из Linux-ового OVAL-контента действительно раскидываются по бюллетеням. Включая CVE-2024-1086. Вот она в феврале:

$ grep "CVE-2024-1086"  bulletins/*
bulletins/2024-02-21.json: "CVE-2024-1086": [
bulletins/2024-02-21.json: "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json: "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json: "title": "CVE-2024-1086 linux",

Ну и пик в мае действительно есть. Да ещё какой! 11 476 CVE! 😱 Настолько много, что я перегенерил Vulristics отчёт для него только с использованием 2 источников: Vulners и БДУ. И даже из Vulners данные подгружались не быстро. В отчёте 77 уязвимостей с признаком активной эксплуатации вживую и 1 404 уязвимости с эксплоитами, но без признаков активной эксплуатации. Т.к. по больше части это уязвимости старые, для которых просто не было понятно когда именно они были исправлены, например, Remote Code Execution - Apache HTTP Server (CVE-2021-42013), я не буду подробно их разбирать - кому интересно смотрите отчёт. Но обратите внимание, что размер отчёта очень большой.

🗒 Отчёт Vulristics по майскому Linux Patch Wednesday (31.3 мб.)

Что касается июньского Linux Patch Wedneday, который финализировался 19 июня, то там 1040 уязвимости. Тоже довольно много. Почему так? С одной стороны правило по Unknown датам добавило 977 Debian-овских OVAL дефинишенов без даты. Не 30к, как в мае, но тоже значительно. Из 1040 уязвимостей 854 это уязвимости Linux Kernel. Причём, довольно много "старых" идентификаторов уязвимостей, но заведенных в 2024 году. Например, CVE-2021-47489 с NVD Published Date 05/22/2024. 🤔 Что-то странное творит CNA Linux Kernel.

🔻 С признаками эксплуатации вживую опять Remote Code Execution - Chromium (CVE-2024-5274, CVE-2024-4947), как и Microsoft Patch Tuesday. Судя по данным БДУ, Remote Code Execution - Libarchive (CVE-2024-26256) также активно эксплуатируется.

🔸 Ещё 20 уязвимостей с публичным эксплоитом. Можно подсветить отдельно Remote Code Execution - Cacti (CVE-2024-25641) и Remote Code Execution - onnx/onnx framework (CVE-2024-5187).

🗒 Отчёт Vulristics по июньскому Linux Patch Wednesday (4.4 мб.)

upd. 30.06 Обновил отчёт.

До End of Life CentOS 7 осталось 2 недели

До End of Life CentOS 7 осталось 2 недели

До End of Life CentOS 7 осталось 2 недели. Самое время проверить не осталось ли где-то в инфраструктуре хостов с этой операционной системой. Куда мигрировать с CentOS 7 не особо понятно. RedHat превратили CentOS в нестабильный дистрибутив CentOS Stream и начали бороться с традиционными альтернативами в виде Alma и Rocky. Можно, конечно, посмотреть в сторону SberLinux, RedOS и Роса «Кобальт», но, имхо, будущее RPM-based дистрибутивов совместимых с RHEL в России достаточно туманно и стоит целиться скорее в Астру или Альт. Судя по статистике, в мире в основном бегут на Ubuntu.

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

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

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

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

Хакатон MaxPatrol VM, часть 1: Linux стенд и Ansible

Хакатон MaxPatrol VM, часть 1: Linux стенд и Ansible

Хакатон MaxPatrol VM, часть 1: Linux стенд и Ansible. Как и обещал, делюсь впечатлениями от хакатона. Первым заданием у меня была автоматизации установки софта из TAR-архива на Debian 12 с помощью Ansible. Раньше я с Ansible толком не работал, поэтому появился повод немного разобраться.

Ansible - система управления конфигурациями, написанная на Python. Главное отличие Ansible от аналогов - не нужна установка агента или клиента на управляемые хосты. Обычно используется для управления Linux-хостами, но Windows также поддерживается. Взаимодействие происходит по модели push: сам Ansible запускается на "центральном" управляющем хосте, ходит на управляемые хосты и что-то делает. На управляемом хосте должен быть установлен Python версии 2.4 и выше, соединение выполняется по SSH или WinRM.

Управляющим хостом для Ansible будет мой десктоп на Ubuntu 23.10, а управляемым хостом будет виртуалка в VirtualBox.

Я завёл виртуалку в VirtualBox с Debian 12, добавил интерфейс Host-only adapter, чтобы можно было подключаться к ней по SSH. Я проверил, что подключение работает с помощью:

$ ssh vmuser@192.168.56.104

Для работы Ansible должна быть настроена аутентификация по ключам. Я сгенерировал ключ с помощью:

$ ssh-keygen -t ed25519 -C "alexander@avleonov.com"

Затем я закинул его на target-host:

$ ssh-copy-id vmuser@192.168.56.104

После этого команда уже не требовала пароль.

На десктоп с Ubuntu 23.10 я поставил Ansible при помощи утилиты pipx

$ sudo apt-get install pipx
$ pipx install --include-deps ansible

Обновлять можно с помощью:

$ pipx upgrade --include-injected ansible

Проверить версию ansible можно с помощью:

$ ansible --version
ansible [core 2.16.7]
...

Далее описываю управляемый хост (виртуалку) в yaml файле:

$ cat hosts.yaml 
myhosts:
hosts:
debian12:
ansible_host: 192.168.56.104

Валидирую файл hosts.yaml:

$ ansible-inventory -i hosts.yaml --list
{
"_meta": {
"hostvars": {
"debian12": {
"ansible_host": "192.168.56.104"
}
}
},
"all": {
"children": [
"ungrouped",
"myhosts"
]
},
"myhosts": {
"hosts": [
"debian12"
]
}
}

Проверяю соединение:

$ ansible myhosts -m ping -i hosts.yaml -u vmuser
debian12 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}

Всё работает, связь есть. Теперь можно попробовать выполнить какие-то команды на хосте с помощью Ansible. Делаю тестовый плейбук для вывода hostname и версии дистрибутива:

- name: Print Hostname and OS Version
hosts: all
tasks:
- name: Get Hostname
command: hostname
register: hostname_output

- name: Get OS Version
ansible.builtin.shell: lsb_release -a | grep "Description:" | awk -F"\t" '{print $2}'
register: os_version_output

- name: Display Outputs
debug:
msg: "Hostname is {{ hostname_output.stdout }} and OS Version is {{ os_version_output.stdout }}"

Запускаю его:

$ ansible-playbook -i hosts.yaml -u 'vmuser' playbook.yaml
...

TASK [Display Outputs] *********************************************************
ok: [debian12] => {
"msg": "Hostname is debian and OS Version is Debian GNU/Linux 12 (bookworm)"
}

Работает! В следующей части рассмотрим как описать в плейбуке установку софта из TAR-архива.