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

Майский Linux Patch Wednesday

Майский Linux Patch Wednesday
Майский Linux Patch WednesdayМайский Linux Patch WednesdayМайский Linux Patch WednesdayМайский Linux Patch WednesdayМайский 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 можно отдельно группировать уязвимости с публичными эксплоитами и приватными эксплоитами, т.к. всё-таки это сильно влияет на критичность. Ставьте 🐳, если нужно такое сделать.

🗒 Отчёт Vulristics по майскому Linux Patch Wednesday

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе

Детектирование известных (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
Для январской 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 тоже подвержен уязвимости. 🤷‍♂️

Закругляю февраль традиционным англоязычным постом и видяшкой

Закругляю февраль традиционным англоязычным постом и видяшкой. 🙂 Чуть-чуть поговорил про опенсурсные проекты (признаться, не было особо времени ими заниматься, пока одни намётки), про PT-шные активности и, естественно, про уязвимости (трендовые и не очень).

———

February 2024: Vulremi, Vuldetta, PT VM Course relaunch, PT TrendVulns digests, Ivanti, Fortinet, MSPT, Linux PW

Hello everyone! In this episode, I will talk about the February updates of my open source projects, also about projects at my main job at Positive Technologies and interesting vulnerabilities.

My Open Source projects
00:14 Vulremi - a simple vulnerability remediation utility
00:55 Vuldetta - an API for detecting vulnerabilities based on a list of Linux packages

Positive Technologies
01:22 Two new video modules for the relaunch of the Vulnerability Management training course
02:00 Monthly digests of trending vulnerabilities

Vulnerabilities
02:17 RCEs in the Ivanti Connect Secure, Ivanti Policy Secure and Ivanti Neurons for ZTA (CVE-2024-21887, CVE-2023-46805, CVE-2024-21893)
03:47 Arbitrary Code Execution vulnerability in Fortinet FortiOS and FortiProxy (CVE-2024-21762)
04:11 Cisco ASA Information Disclosure vulnerability (CVE-2020-3259) is used by the Akira ransomware
04:55 February Microsoft Patch Tuesday
07:14 February Linux Patch Wednesday

🎞 Video
📘 Blogpost
🎞 VKVideo

Прошла третья среда месяца, а значит пора смотреть февральский Linux Patch Wednesday

Прошла третья среда месяца, а значит пора смотреть февральский Linux Patch WednesdayПрошла третья среда месяца, а значит пора смотреть февральский Linux Patch WednesdayПрошла третья среда месяца, а значит пора смотреть февральский Linux Patch WednesdayПрошла третья среда месяца, а значит пора смотреть февральский Linux Patch WednesdayПрошла третья среда месяца, а значит пора смотреть февральский Linux Patch Wednesday

Прошла третья среда месяца, а значит пора смотреть февральский Linux Patch Wednesday. 149 уязвимостей. Среди них нет уязвимостей с признаком активной эксплуатации. 20 уязвимостей с PoC-ами/эксплоитами. На первый взгляд все громкие уязвимости прошедшего месяца на месте:

🔻 Elevation of Privilege - GNU C Library (CVE-2023-6246). Это очередная уязвимость glibc, которую нашли Qualys.
🔻 Information Disclosure - runc (CVE-2024-21626). Побег из контейнера.
🔻 Denial of Service - dnsmasq (CVE-2023-50387). Это про атаку 'KeyTrap' на DNSSEC.
🔻 Authentication Bypass - Sudo (CVE-2023-42465). Про эту новостей не видел, её запатчили в RPM-based дистрибах на прошлой неделе.

🗒 Февральский Linux Patch Wednesday

Прожектор по ИБ, выпуск №22 (10.02.2024): Вижу MacBook — мне неприятно

Прожектор по ИБ, выпуск №22 (10.02.2024): Вижу MacBook — мне неприятно

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

00:00 Здороваемся, смотрим статистику, разгоняем про продукты Apple
03:31 Где был Лев: Собираем карьеру с Евгением Питолиным и дебаты на AM Live
09:42 4 апреля состоится форум "Территория Безопасности - 2024: все pro ИБ"
13:42 Мем про тяжелую неделю для Fortinet
14:21 RCE-уязвимость в Fortinet FortiOS и FortiProxy (CVE-2024-21762) эксплуатируется вживую
19:16 Fortinet исправила две критические уязвимости максимальной степени серьезности в FortiSIEM
21:06 Очередная AuthBypass уязвимость в Ivanti Connect Secure, Ivanti Policy Secure и ZTA (CVE-2024-22024)
23:02 Занимательная статья от исследователей уязвимостей из PT SWARM
28:51 Взлом компании AnyDesk и рекомендации от НКЦКИ
33:51 Нужен ли Антивирус (или шире - Endpoint Protection) на Linux хостах?
41:33 Бывшего сотрудника Apple приговорили к тюремному заключению за кражу данных об автомобиле
44:47 Исследователя безопасности обвинили в попытке получить около $3 млн долларов от Apple в виде продукции и услуг компании
49:38 Что такое Игры Будущего 2024?
53:03 Банк России составил портрет жертвы кибермошенников
55:26 🎤 Mr. X и Олег Тиньков (признан иностранным агентом 16.02.2024, уже после публикации видео) поясняют за этот эпизод Прожектора по ИБ