Сейчас начинают потихоньку разгонять [1, 2] по поводу уязвимости macOS CVE-2022-32910

1 комментарий

Сейчас начинают потихоньку разгонять [1, 2] по поводу уязвимости macOS CVE-2022-32910

Сейчас начинают потихоньку разгонять [1, 2] по поводу уязвимости macOS CVE-2022-32910. Прочитал исследование. Может я что-то не понял, но похоже из мухи слона делают. Описание-то прямо страшное: "Jamf Threat Labs recently discovered a new macOS vulnerability in Archive Utility that could lead to the execution of an unsigned and unnotarized application without displaying security prompts to the user, by using a specially crafted archive". Можно подумать, что скачал пользователь архив, кликнул по нему случайно и всё, похачен.

На самом деле там пишут про вот этот механизм macOS:

"Когда архив загружается из Интернета, он будет содержать расширенный атрибут com.apple.quarantine. Этот расширенный атрибут укажет macOS, что файл был загружен из удаленного источника и должен быть проверен, прежде чем будет разрешено его выполнение. Когда утилита архивирования извлекает архив, она применяет атрибут карантина ко всем извлеченным элементам. Это обеспечивает соответствующее распространение атрибута карантина и проверку Gatekeeper-ом любых открытых исполняемых файлов".

И вот простановку атрибута com.apple.quarantine (и проверку Gatekeeper) исследователи научились обходить.

"Когда пользователь загружает и запускает такой архив, он будет открыт Archive Utility в следующем виде. [картинка] Как мы видим, приложение не имеет атрибута карантина и, следовательно, будет обходить все проверки гейткипера, позволяя выполняться unnotarized a и/или неподписанным двоичным файлам."

То есть пользователь должен скачать архив и запустить оттуда зловредное приложение и тогда ему не дадут по рукам встроенные механизмы безопасности. Но возможно дадут по рукам какие-то другие механизмы безопасности.

В общем, уязвимость это? Уязвимость. Критикал ли это, который нужно срочно патчить? Ну вроде нет. Возможно повод научиться искать подобные архивы в почте.

Интересный пост вышел вчера в блоге Qualys

Добавить комментарий

Интересный пост вышел вчера в блоге Qualys. Про устаревшие активы. Суть в следующем. В ходе эксплуатации Vulnerability Management системы в неё добавляются активы. В основном сетевые хосты, но в случае Qualys не только. На них каким-то образом, агентно или безагентно детектируются уязвимости. И вот по какой-то причине данные по некоторому активу перестают обновляться. Как правило, это связано с тем что актива больше нет. Сервер выключили, виртуалку удалили, десктоп перезалили и т.п. А в интерфейсе Qualys актив продолжает отображаться, для него показываются уязвимости, он в лицензии учитывается. Непорядок.

И какую же функциональность предлагает Qualys для решения этой проблемы? Во-первых отображают активы в дашборде, с разбивкой по дате последнего обновления данных. Уже неплохо. Как минимум можно поресерчить что с этими активами случилось. Во-вторых можно настроить правила, которые будут активы неактивные больше N дней удалять. Это конечно не самое хорошее решение, десятки дней терпеть в VM-е зомби-хосты и неисправляемые уязвимости на них. Но зато просто. И эти правила не работают для "IP/DNS/NetBIOS tracked scanned assets (no Cloud Agent)", для них там ручной метод предлагается.

Но, имхо, самое лучшее решение, о котором в посте не пишут это забирать актуальные статусы активов непосредственно из IT-систем через которые они управляются, залезать в VM решение по API и оперативно подчищать неживое. Благо у Qualys API мощный и такие штуки можно делать без проблем. Кастомная автоматизация рулит! 🙂

Занимательно порефлексировать над очередным набросом Дурова на WhatsApp

Добавить комментарий

Занимательно порефлексировать над очередным набросом Дурова на WhatsApp. Он там делает далеко идущие выводы, что очередная исправленная RCE уязвимость в WhatsApp это на самом деле умышленно добавленный бэкдор. 🙂 И что эта уязвимость давала доступ ко всем файлам на телефоне пользователей. И поэтому ради безопасности своих данных не пользуйтесь WhatsApp-ом.

Нет, ну что такая атака с использованием WhatsApp в принципе возможна, мы ещё по кейсу с Pegasus от NSO Group помним. Но не настолько же все тривиально! То, что используется в десятках таргетированных атак вряд ли будет долго и массово использоваться против простых обывателей.

С тем же успехом можно сказать, что, например, уязвимость в виндовом клиенте Telegram это тоже был бэкдор. 🙂

С другой стороны, является ли смартфон с удаленным ватсапом или даже телеграммом безопасным устройством? Нет конечно! Он как был убогой пальцетыкалкой с нелепым обрубком вместо операционной системы так и остался. Обрубком, который был вкорячен на конкретную железку матюками и грязными хаками, так что поставить туда что-то альтернативное в общем случае не получится, только попользоваться пару лет и выкинуть. На каждый чих по приложению требующему максимум прав. Дичь ведь. И всё это намертво завязано на американский бигтех и им же полность контролируется. Использовать смартфон с Android или iOS для чего-то чем вы не готовы сейчас же поделиться со всем миром это очень плохая идея. Если вы так делаете, прекращайте.

Поискал что же это за документ такой калифорнийский

Добавить комментарий

Поискал что же это за документ такой калифорнийский. Кажется вот этот.
https://cdt.ca.gov/wp-content/uploads/2021/10/Cybersecurity_Strategy_Plan_FINAL.pdf
Как видно из урла, прошлогодний. Ну и страниц не 24, а 15. Но не суть, надеюсь у них с внедрением VM-а все получилось. 🙂

Читаю Лукацкого с карандашиком

Добавить комментарий

Читаю Лукацкого с карандашиком

Читаю Лукацкого с карандашиком. 🙂 "Пятилетний план по кибербезопасности штата Калифорния. Слева технические меры, которые должны быть внедрены во всех госструктурах штата разнесенные по приоритетам." Continuous Vulnerability Management в P1, Patch Management в P2. Приоритетами удовлетворен. 😊

Тут ещё недавно была очень крутая инициатива от CISA (BOD) 23-01, надо будет её по-внимательнее почитать и расписать. На первый взгляд и в пересказе журналистов нашим дорогим регуляторам было бы тоже интересно ознакомиться.

Собственно вот и обещанный пост про OpenSCAP

Добавить комментарий

Собственно вот и обещанный пост про OpenSCAP. Демонстрирую как можно просканить хост на уязвимости с помощью OpenSCAP и бесплатного официального OVAL контента для Ubuntu. Также пробую разнести сбор данных и их анализ с помощью System Characteristics. Не без багов, но работает. Можно ли будет генерить файлы System Characteristics самостоятельно без утилиты oscap, только по собранным пакетам и версии ОС? Так чтобы на основе OpenSCAP сделать бесплатную API-шку совместимую со Scanvus? 🤓 Хе-хе, посмотрим. Но пока выглядит как достаточно перспективная задумка. Следите за обновлениями, ну и если кто хочет поучаствовать в благом деле, пишите в личку (@leonov_av).

Итак, вы решили начать разработку своего Vulnerability Management решения

2 комментария

Итак, вы решили начать разработку своего Vulnerability Management решения. Часть 3. На чем можно срезать углы?

Подводные камни подсветили, специализаций коснулись. В этой завершающей части посмотрим как можно быстро слепить VM-решение из того, что есть в паблике:

1. Весьма соблазнительно взять опенсурсный сканер и, несколько доработав его, начать продавать как коммерческий продукт или сервис. Например, взять OpenVAS/GVM, Nuclei, Nmap. Однако следует понимать, что вместе с наработками придется брать в нагрузку и немалое легаси. И возможно реализовать какую-то конкретную функциональность с нуля было бы проще, чем поддерживать форк проекта с историей. Кроме того за успешным опенсурсным сканером, как правило, стоит коммерческая компания, которая этот проект уже монетизирует и конкурентам не рада. Стоит ожидать, что вам будут вставлять палки в колеса, например через хитрое лицензирование (Nmap) или ограничение бесплатного публичного фида с детектами (OpenVAS/GVM). И тут уж как впишитесь.
2. Часто для того, чтобы по-быстрому добавить детектирование уязвимостей реализуют такую схему: детектирование CPE идентификатора установленного софта и поиск уязвимостей в базе NVD. Просто, быстро, универсально. Но далеко не всегда достоверно, т.к. ошибки могут быть и при детектировании CPE, и описании уязвимой конфигурации в NVD. Да и не всё всегда определяется версиями софта, свою роль могут играть патчи и их перекрытия. Продемонстрировать как такая схема работает можно на примере Nmap + Vulners plugin. Nmap тут отвечает за детект CPE, а Vulners за поиск по NVD.
3. Отдельная большая тема это SCAP/OVAL. Если кратко, то это набор открытых спецификаций для описания уязвимостей/мисконфигураций и того как их по этому описанию детектировать. Есть много бесплатного публичного контента: репозиторий CIS, DISA STIGs, профили PCI DSS от OpenSCAP, Windows уязвимости в коненте от ФСТЭК/АЛТЭКС-СОФТ, вендорский контент для Ubuntu, Debian, RHEL. Есть как минимум один опенсурсный SCAP/OVAL сканер, который все ещё развивается, это OpenSCAP от RedHat. Есть старые заброшенные проекты ovaldi и jovaldi. C открытыми SCAP/OVAL сканерами под Windows все традиционно тяжко, OpenSCAP в этом направлении шел, но не так давно под Windows его перестали поддерживать. Следует отметить, что продвигается эта тема в первую очередь американцами для контроля безопасности их государственной инфры (для военных и федеральных агентств в основном). Чуть менее чем все вакансии по SCAP/OVAL открываются в США и требуют американское гражданство и clearance, что намекает. 😉 Также они навязывают VM-вендорам поддерживать SCAP/OVAL, что те и делают, кто-то более формально, кто-то менее. В общем, есть соблазн в это дело крепко влезть, чтобы реюзнуть наработки. И есть как минимум одна success story у кого это получилось - RedCheck от АЛТЭКС-СОФТ. Также можно привести в пример индийскую компанию Secpod. Из минусов - спецификации там не особо простые и удобные, делать всё строго по ним достаточно тяжко, особенно реализовывать нестандартные проверки для нестандартных систем.

На этом мини-цикл про разработку VM я заканчиваю, но тему сканероделания конечно не оставляю. Дальше как раз планирую в очередной раз погружаться в SCAP/OVAL, следующий плановый эпизод будет про детектирование уязвимостей с помощью OpenSCAP.