До End of Life CentOS 7 осталось 2 недели. Самое время проверить не осталось ли где-то в инфраструктуре хостов с этой операционной системой. Куда мигрировать с CentOS 7 не особо понятно. RedHat превратили CentOS в нестабильный дистрибутив CentOS Stream и начали бороться с традиционными альтернативами в виде Alma и Rocky. Можно, конечно, посмотреть в сторону SberLinux, RedOS и Роса «Кобальт», но, имхо, будущее RPM-based дистрибутивов совместимых с RHEL в России достаточно туманно и стоит целиться скорее в Астру или Альт. Судя по статистике, в мире в основном бегут на Ubuntu.
Архив метки: Linux
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. Как и обещал, делюсь впечатлениями от хакатона. Первым заданием у меня была автоматизации установки софта из 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-архива.
Майский Linux Patch Wednesday
Майский Linux Patch Wednesday. В прошлом месяце мы совместно решили, что стоит ввести правило по Unknown датам с мая 2024. Что я, собственно, и реализовал. Теперь, если я вижу oval definition, для которого нет даты публикации (даты появления исправлений для соответствующих уязвимостей), то я номинально присваиваю сегодняшнюю дату. Таким образом 32406 oval definition-ов без даты получили номинальную дату 2024-05-15. Можно было бы предположить, что мы получим огромный пик для уязвимостей, которые "начали исправляться в мае" исходя из номинальной даты. А как вышло на самом деле?
На самом деле пик получился не очень большой. В майском Linux Patch Wednesday 424 CVE. При том, что в апрельском было 348. Соизмеримо. Видимо не очень большой пик связан с тем, что для большей части уязвимостей уже были даты исправления старше выставленной номинальной (2024-05-15). Тем лучше. 🙂 В июне всё должно стать вообще хорошо.
Как обычно, я сгенерировал отчёт Vulristics для майских уязвимостей. Большая часть уязвимостей (282) относятся к Linux Kernel. Это следствие того, что Linuх Kernel теперь CNA и они могут заводить CVE на всякую дичь типа багов с огромными трейсами прямо в описании уязвимостей.
На первом месте уязвимость из CISA KEV.
🔻Path Traversal - Openfire (CVE-2023-32315). Это трендовая уязвимость августа 2023 года. Она попала в отчёт из-за фикса в RedOS 2024-05-03. А в других Linux дистрибутивах её не фиксили? Похоже, что нет. В Vulners среди связанных объектов безопасности можем видеть только бюллетень RedOS. Видимо в репозиториях других дистрибутивов пакеты Openfire отсутствуют.
На втором месте уязвимость с признаком активной эксплуатации по AttackerKB.
🔻 Path Traversal - aiohttp (CVE-2024-23334). Ошибка позволяет неаутентифицированным злоумышленникам получать доступ к файлам на уязвимых серверах.
По данным из БДУ ещё 16 уязвимостей имеют признаки активной эксплуатации вживую.
🔻 Memory Corruption - nghttp2 (CVE-2024-27983)
🔻 Memory Corruption - Chromium (CVE-2024-3832, CVE-2024-3833, CVE-2024-3834, CVE-2024-4671)
🔻 Memory Corruption - FreeRDP (CVE-2024-32041, CVE-2024-32458, CVE-2024-32459, CVE-2024-32460)
🔻 Memory Corruption - Mozilla Firefox (CVE-2024-3855, CVE-2024-3856)
🔻 Security Feature Bypass - bluetooth_core_specification (CVE-2023-24023)
🔻 Security Feature Bypass - Chromium (CVE-2024-3838)
🔻 Denial of Service - HTTP/2 (CVE-2023-45288)
🔻 Denial of Service - nghttp2 (CVE-2024-28182)
🔻 Incorrect Calculation - FreeRDP (CVE-2024-32040)
Ещё для 22 уязвимостей есть эксплоит (публичный или приватный), но пока нет признаков активной эксплуатации вживую. Все их здесь перечислять не буду, можно обратить внимание на:
🔸 Security Feature Bypass - putty (CVE-2024-31497). Громкая уязвимость, позволяющая атакующему восстановить секретный ключ пользователя.
🔸 Remote Code Execution - GNU C Library (CVE-2014-9984)
🔸 Remote Code Execution - Flatpak (CVE-2024-32462)
🔸 Command Injection - aiohttp (CVE-2024-23829)
🔸 Security Feature Bypass - FreeIPA (CVE-2024-1481)
Думаю, что в качестве улучшения в отчёте Vulristics можно отдельно группировать уязвимости с публичными эксплоитами и приватными эксплоитами, т.к. всё-таки это сильно влияет на критичность. Ставьте 🐳, если нужно такое сделать.
Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе
Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе. Что достаточно расставить агенты по хостам. А те хосты, куда агенты установить нельзя, например сетевые устройства, достаточно сканировать с аутентификацией. Дескать сканы без аутентификации всегда менее достоверны, чем сканы с аутентификацией, и нужны они только для сканирования периметра или первичной инвентаризации сети. На мой взгляд, это не совсем правильно. Сканировать без аутентификации на наличие известных уязвимостей, обязательно нужно, особенно в случае хостов с веб-приложениями.
И связано это именно с особенностями детектирования уязвимостей при сканировании с аутентификацией. Возьмём Linux-хосты. Как правило, VM-вендоры при сканировании Linux-хостов с аутентификацией ограничиваются детектированием уязвимостей в пакетах из официального репозитория Linux-вендора. 🤷♂️ Просто потому, что эти уязвимости описываются в общедоступных бюллетенях безопасности или даже в виде формализованного OVAL-контента. Удобно. Научился работать с этим контентом и можно ставить галочку, что Linux-дистриб поддерживается VM-решением. А как насчёт уязвимостей софта, который отсутствует в официальном репозитории Linux-вендора? Вот тут всё сложнее.
Такой софт может быть установлен:
🔹 Из подключенного стороннего репозитория
🔹 Из пакета (вендорского или самосборного) стандартной пакетной системы дистрибутива (deb, rpm), который принесли на хост ручками
🔹 Из альтернативных пакетов для распространения софта (snap, flatpak, appimage и т.д.)
🔹 Из средств распространения модулей (pip, conda, npm и т.д.)
🔹 Из образа контейнера (docker, podman и т.д.)
🔹 Из исходников софта, при этом сборка софта может происходить на том же хосте или собранный софт может быть перенесён в виде бинарных файлов
В идеале, независимо от способа установки софта на хосте, сканер уязвимостей должен его корректно продетектировать, определить его версию, а по версии определить связанные уязвимости. 🧙♂️ Но на практике, из-за того что способов установки софта множество, это весьма нетривиальная задача. 🧐
В итоге мы получаем ситуацию: допустим, у нас есть какой-то коммерческий или опенсурсный софт на Linux-хосте (Zabbix, GitLab, Confluence, Jira). Рыская по хосту по SSH этот софт не так-то просто надёжно найти. А при взгляде на хост извне, он ищется тривиально: сканируем порты, находим web-GUI, зачастую на главной странице находим версию и по ней детектируем уязвимости. При этом мы вообще не зависим от конкретного способа установки и запуска софта на хосте. Главное, что мы сам веб-интерфейс приложения видим. 🤩
Такие "внешние" правила детектирования уязвимостей и самим гораздо проще разрабатывать, и открытой экспертизой можно воспользоваться. Фингерпринтинг для получения CPE в сочетании с поиском в NVD по CPE это, конечно, грязный способ. Зато массовый. 😏 И если грамотно подтачивать и фингепринтилку, и правила детектирования по CPE, то и количество фолзов можно уменьшить до приемлемого уровня. А если ещё и добавить валидацию с помощью проверок с попыткой эксплуатации уязвимости (подтянуть nuclei тот же), то значительный набор уязвимостей можно будет детектировать более чем надежно. 😉
В общем, "пентест"-сканирование для определения известных уязвимостей - must have и для внутрянки тоже, особенно для веб-приложений.
А проприетарное лучше?
А проприетарное лучше? Несмотря на то, что я сам Linux-оид и мне эта ОС наиболее комфортна, я не особо рад, что у нас импортозамещение идёт в сторону использования Linux-а. Парадокс. 🤷♂️ Использование Linux подразумевает доверие к коду, который написан непонятно кем и непонятно как. И любой коммерческий Linux-вендор контролирует его постольку-поскольку, даже если это Canonical, RedHat и Suse. Эффективного способа препятствовать там закладкам не наблюдается. Всё на доверии. 😏 И даже в случае обнаружения закладки спросить-то не с кого: крайним будет очередной мутный Jia Tan. 🤡
Имхо, было бы гораздо лучше, если бы в России доминировала "российская macOS". Т.е. проприетарная POSIX-овая ОС от отечественной компании, которая несла бы ответственность за весь её код. Ближе всего к этому выглядит KasperskyOS. Амбиции сделать универсальную ОС у компании были. Будем ждать.
Но пока вероятнее, что будем лететь на более-менее стандартном Linux со всеми сопутствующими рисками.
Для январской Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) 26 марта вышел write-up и PoC
Для январской Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) 26 марта вышел write-up и PoC. Видео демка работы скрипта выглядит эффектно: запускают скрипт от обычного пользователя и через пару секунд получают рутовый шелл. ⚡️ По заявлениям автора эксплоит работает с большинством ядер Linux между версиями 5.14 и 6.6, включая Debian, Ubuntu и KernelCTF.
🔻 Эксплойт требует kconfig CONFIG_USER_NS=y; sh command sysctl kernel.unprivileged_userns_clone = 1; kconfig CONFIG_NF_TABLES=y. Автор пишет, что это по дефолту выполняется для Debian, Ubuntu, and KernelCTF, а для других дистрибов нужно тестить.
🔹 Эксплойт не работает на ядрах v6.4> с kconfig CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y (включая Ubuntu v6.5)
NSFOCUS пишет, что Redhat тоже подвержен уязвимости. 🤷♂️