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

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

ТОП 5 CVE, которые чаще других эксплуатировались пентестерами Pos­i­tive Tech­nolo­gies в 2023 году. Отчёт вышел 2 июля.

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

🔻 Remote Code Exe­cu­tion — Microsoft Exchange "Prox­yNot­Shell" (CVE-2022–41040, CVE-2022–41080, CVE-2022–41082)
🔻 Remote Code Exe­cu­tion — Bitrix Site Man­ag­er "PollsVotes" (CVE-2022–27228)
🔻 Ele­va­tion of Priv­i­lege — Polk­it "PwnKit" (CVE-2021–4034)

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

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

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

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

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

Самый популярный почтовый сервак
MS Exchange — лакомая цель любых атак.
3 уязвимости Prox­yNot­Shell — по сути одна
Remote Code Exe­cu­tion. Опасность наглядно видна.

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

Ну а если злоумышленник
На Lin­ux хост проник
И там спокойно сидит,
Нет надёжнее стратегии,
Чем поднять до root‑a привилегии
Через уязвимость Polk­it, PwnKit.

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

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

MP3 файл

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

Трендовые уязвимости июня по версии Pos­i­tive Tech­nolo­gies. Традиционно в 3 форматах:

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

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

🔻 EoP в Microsoft Win­dows CSC (CVE-2024–26229)
🔻 EoP в Microsoft Win­dows Error Report­ing (CVE-2024–26169)
🔻 EoP в Microsoft Win­dows Ker­nel (CVE-2024–30088)
🔻 RCE в PHP (CVE-2024–4577)
🔻 EoP в Lin­ux Ker­nel (CVE-2024–1086)
🔻 InfDis­clo­sure в Check Point Secu­ri­ty Gate­ways (CVE-2024–24919)
🔻 RCE в VMware vCen­ter (CVE-2024–37079, CVE-2024–37080)
🔻 Auth­By­pass в Veeam Back­up & Repli­ca­tion (CVE-2024–29849)

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

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

Обновил июньский Lin­ux Patch Wednes­day и перевыпустил отчёт Vul­ris­tics. Общее количество уязвимостей снизилось с 1053 до 1040. Видимо для них стали доступны более ранние таймстемпы фиксов. Но уязвимости с признаком эксплуатации вживую и с публичным эксплоитом это не зацепило, они остались теми же.

🗒 Отчёт Vul­ris­tics по июньскому Lin­ux Patch Wednes­day

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

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

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

То, что не все CVE-шки у меня попадаются в LPW бюллетени, несмотря на введение номинальных дат, я заметил на примере громкой уязвимости Ele­va­tion of Priv­i­lege (Local Priv­i­lege Esca­la­tion) — Lin­ux Ker­nel (CVE-2024–1086), которой действительно нигде не было. Подебажил функцию распределения по бюллетеням, добавил тесты. Добился того, что все 38 362 CVE-шки из Lin­ux-ового 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! 😱 Настолько много, что я перегенерил Vul­ris­tics отчёт для него только с использованием 2 источников: Vul­ners и БДУ. И даже из Vul­ners данные подгружались не быстро. В отчёте 77 уязвимостей с признаком активной эксплуатации вживую и 1 404 уязвимости с эксплоитами, но без признаков активной эксплуатации. Т.к. по больше части это уязвимости старые, для которых просто не было понятно когда именно они были исправлены, например, Remote Code Exe­cu­tion — Apache HTTP Serv­er (CVE-2021–42013), я не буду подробно их разбирать — кому интересно смотрите отчёт. Но обратите внимание, что размер отчёта очень большой.

🗒 Отчёт Vul­ris­tics по майскому Lin­ux Patch Wednes­day (31.3 мб.)

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

🔻 С признаками эксплуатации вживую опять Remote Code Exe­cu­tion — Chromi­um (CVE-2024–5274, CVE-2024–4947), как и Microsoft Patch Tues­day. Судя по данным БДУ, Remote Code Exe­cu­tion — Libarchive (CVE-2024–26256) также активно эксплуатируется.

🔸 Ещё 20 уязвимостей с публичным эксплоитом. Можно подсветить отдельно Remote Code Exe­cu­tion — Cac­ti (CVE-2024–25641) и Remote Code Exe­cu­tion — onnx/onnx frame­work (CVE-2024–5187).

🗒 Отчёт Vul­ris­tics по июньскому Lin­ux Patch Wednes­day (4.4 мб.)

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

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

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

До End of Life Cen­tOS 7 осталось 2 недели. Самое время проверить не осталось ли где-то в инфраструктуре хостов с этой операционной системой. Куда мигрировать с Cen­tOS 7 не особо понятно. Red­Hat превратили Cen­tOS в нестабильный дистрибутив Cen­tOS Stream и начали бороться с традиционными альтернативами в виде Alma и Rocky. Можно, конечно, посмотреть в сторону Sber­Lin­ux, RedOS и Роса «Кобальт», но, имхо, будущее RPM-based дистрибутивов совместимых с RHEL в России достаточно туманно и стоит целиться скорее в Астру или Альт. Судя по статистике, в мире в основном бегут на Ubun­tu.

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

Ele­va­tion of Priv­i­lege (Local Priv­i­lege Esca­la­tion) — Lin­ux Ker­nel (CVE-2024–1086) добавили в CISA KEV. Сама уязвимость относительно старая, январская. Я уже писал про неё в марте, когда вышел write-up и публичный эксплоит.

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

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

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

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

Хакатон Max­Pa­trol VM, часть 1: Lin­ux стенд и Ansi­ble. Как и обещал, делюсь впечатлениями от хакатона. Первым заданием у меня была автоматизации установки софта из TAR-архива на Debian 12 с помощью Ansi­ble. Раньше я с Ansi­ble толком не работал, поэтому появился повод немного разобраться.

Ansi­ble — система управления конфигурациями, написанная на Python. Главное отличие Ansi­ble от аналогов — не нужна установка агента или клиента на управляемые хосты. Обычно используется для управления Lin­ux-хостами, но Win­dows также поддерживается. Взаимодействие происходит по модели push: сам Ansi­ble запускается на "центральном" управляющем хосте, ходит на управляемые хосты и что-то делает. На управляемом хосте должен быть установлен Python версии 2.4 и выше, соединение выполняется по SSH или Win­RM.

Управляющим хостом для Ansi­ble будет мой десктоп на Ubun­tu 23.10, а управляемым хостом будет виртуалка в Vir­tu­al­Box.

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

$ ssh vmuser@192.168.56.104

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

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

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

$ ssh-copy-id vmuser@192.168.56.104

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

На десктоп с Ubun­tu 23.10 я поставил Ansi­ble при помощи утилиты pipx

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

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

$ pipx upgrade --include-injected ansible

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

$ 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"
}

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

- 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-архива.