Архив рубрики: Уязвимости

Вышла занимательная статья про то, что переход с iPhone на китайские Android-смартфоны это так себе идея с точки зрения безопасности

Вышла занимательная статья про то, что переход с iPhone на китайские Android-смартфоны это так себе идея с точки зрения безопасности. Если резюмировать написанное, то там про то, что у Apple всё централизовано, а у китайских производителей смартфонов сплошной разброд и шатание:

1. Уязвимости они закрывают хуже и медленнее.
2. Телеметрии и персональных данных собирают больше.
3. В магазинах приложений там всякие "фонарики" со зловредной функциональностью.
4. APK-шки разрешают ставить скаченные непонятно откуда.
5. Иногда могут предустановленные на заводе бэкдоры содержать.
6. Разнообразных драйверов больше, соответственно уязвимостей в них больше.
7. Для Android сформировался чёрный рынок малварей.

В целом, со всем можно согласиться, но есть 2 передёргивания:

1. Игнорируется тот факт, что Apple обвинили в намеренном внесении бэкдора. После этого называть Apple iOS "сравнительно более безопасной мобильной ОС" это такоё себе. Ну правда, о какой безопасности говорить, если вендор специально бэкдоры вставляет, которые используются в таргетированных атаках.
2. Сравнивать надо сравнимое. Устройства на Apple iOS надо сравнивать с устройствами какого-то конкретного вендора, а не с условным китайским ноунейм вендором Android-смартфонов, навешивая на него проблемы из всех кейсов за последние 15 лет. Если брать топовых вендоров, таких как Xiaomi и Huawei, и их актуальные модели, то там с безопасностью всё совсем не так плохо.

Хотя с тем, что от регуляторов желательно было бы видеть не только рекомендацию отказываться от устройств Apple, но и рекомендацию переходить "на российские мобильные устройства и операционные системы", я полностью согласен. Было бы также здорово, если бы эти устройства появились уже в свободной продаже для физиков.

В начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложений

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

В начале августа Qualys представили новые возможности по анализу уязвимостей самописных (First-Party) и опенсурсных приложений.

Вот, допустим, есть у вас в организации самописная софтина. Её пилят ваши разрабы. Естественно на основе опенсурса. Возможно ваши апсеки периодически проверяют её SAST-ом/DAST-ом и детектят-исправляют уязвимости. Но ваше VM-решение об этой софтине не знает и, соответственно, уязвимости для неё не детектирует. Более того, даже если вы знаете, что версии этой софтины уязвимых софтов. Причём какие-то софты явно забыли и VM-решения в таких софтах Log4Shell не продетектируют. Как и в вашей доморощенной софтине, которая также использует Log4j. Получается такое детектить надо не от софта, а непосредственно от либы, jar-ники искать и анализировать каким-то сторонним решением. И эта активность тоже, получается идёт мимо вашего дорогущего VM-а. Плохо это? Плохо. Зачем VM брали-то тогда! 🙄😁

Что предлагает Qualys. Во всяком случае то, что я понял из достаточно пространной видяшки и поста.

1. Custom Assessment and Remediation (CAR), о котором я раньше уже писал. Это механизм для добавления собственных скриптовых детектов, в том числе на PowerShell и Python. Написали свой скрипт детекта (например по версиям, которые вам апсеки сказали), добавили в Qualys - получили уязвимые хосты. Такие уязвимости будут иметь QID и с ними можно работать как с уязвимостями, которые продетектил сам Qualys.

2. Runtime Software Composition Analysis (SCA). Это композиционный анализ. Во время сканирования на наличие уязвимостей детектируется не только сам софт и его версия, но и используемые этим софтом библиотеки.

"SCA сканирует уязвимости в компонентах с открытым исходным кодом, разработанных для Java, Go, .Net, Python, Node JS, Rust, Ruby, PHP и других. Добавление SCA расширяет возможности сканирования VMDR, добавляя более 13 000 новых сигнатур, охватывающих более 11 000 CVE."

Фактически это сводится к тому, что Qualys Agent бегает по файловой системе и ищет/анализирует файлики библиотек (в т.ч. Log4j). Это не супер-новшество. Такие детекты я давно видел в Microsoft Defender for Endpoint. Видимо это становится обязательной фичой.

В общем, VM-вендоры, присмотритесь к кейсам! Клиенты VM-вендоров, задавайте им неудобные вопросы! 😉

Также на прошлой неделе разобрался как экспортировать уязвимости из on-prem инсталляции VulnsIO через API

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

Также на прошлой неделе разобрался как экспортировать уязвимости из on-prem инсталляции VulnsIO через API. Описания RestAPI в паблике пока нет, т.к. оно сейчас в активной разработке. Запрашивайте через поддержку, скинут очень качественно описанный swagger-файл. 👍 Экспортировать уязвимости просто:

1. API доступен по 443 порту, где и web-интерфейс - удобно. upd 01.09. Теперь ключ выпускается в веб-интерфейсе. Прописываем ключ в x-api-key хидер.

2. Забираем список всех активов. Одним запросом без пагинации.

3. Для каждого актива можно получить список аудитов (сканов). Получаем последний скан через .

4. Разбираем ссылки на CVE в vulnerableObjects.

📄 Выкладываю python-скрипт, в котором формирую дикт, где для каждого хостнейма хранится список cve-шек и дата сканирования.

В общем, хорошая интуитивная API-шка. 👍 Накидал скрипт очень быстро и без затыков.

На неделе разобрался как экспортировать уязвимости из RedCheck через API

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

На неделе разобрался как экспортировать уязвимости из RedCheck через API. Всё достаточно просто. Описание API есть в паблике, вроде оно вполне себе RESTful. Также у API сервера есть встроенный swagger. Порядок действий для экспорта уязвимостей следующий:

1. По логину-паролю пользователя RedCheck получаем токен, который нужно прописывать в заголовки запросов для аутентификации.

2. Забираем все хосты, заведённые в RedCheck.

3. Для каждого хоста через специальный метод получаем уязвимости из последнего скана. Обратите внимание, что обязательно нужно указать тип скана (для аудита уязвимостей Type=5).

4. Информация по уязвимостям хранится в структуре "ovalDefinitions", но XML парсить не придётся, т.к. всё уже удобно разложено в JSON-е. 😊 CVEшки забираем из references.

В общем, нормальная APIшка, жить можно. 🙂👍

Многочисленные уязвимости в компоненте J-Web (веб-консоль) операционной системы Juniper Networks Junos на устройствах серий SRX и EX

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

Многочисленные уязвимости в компоненте J-Web (веб-консоль) операционной системы Juniper Networks Junos на устройствах серий SRX и EX. Путем последовательной эксплуатации четырёх уязвимостей, неаутентифицированный сетевой злоумышленник может удалённо выполнять код на устройствах.

Тем, кто ещё не импортозаместил свои джуны, нужно либо обновляться, либо отключать J-Web, либо максимально ограничивать к нему доступ. Киньте своим сетевикам.

Об атаках с использованием этих уязвимостей не пишут, но их исправили в рамках внеочередного обновления ("Out-of-Cycle Security Bulletin").

PS: сегодня я узнал, что "juniper" это можжевельник, "род вечнозелёных хвойных кустарников и деревьев семейства Кипарисовые". 🙂 А "cisco" это вид лососевых рыб, ряпушка, "озёрная сельдь".

Свежая RCE уязвимость CVE-2023-40477 в WinRAR версиях

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

Свежая RCE уязвимость CVE-2023-40477 в WinRAR версиях 6.23. Для успешной эксплуатации пользователь должен открыть вредоносный rar-архив, который к нему может попасть в рамках фишинговой рассылки например. Уязвимость раскрыли через ZDI.

Архиватор Рошала в России это больше чем просто архиватор. Так уж исторически сложилось. Но, несмотря на российские корни, WinRAR это ПО иностранное, т.к. "официальный издатель продуктов RARLAB" это немецкая win.rar GmbH. И, несмотря на фактическую бесплатность, это shareware, так что если WinRAR у вас в организации используется без лицензии, то к этому могут быть вопросы. Лучше выпиливайте.

Алексей Лукацкий вкинул сегодня вопрос: "Почему вендора, делающие вклад в развитие CVSS, сами его не используют, стараясь придумать что-то свое?"

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

Алексей Лукацкий вкинул сегодня вопрос: "Почему вендора, делающие вклад в развитие CVSS, сами его не используют, стараясь придумать что-то свое?" Он проиллюстрировал это тем, как Microsoft проставляет свой уровень критичности для уязвимости без привязки к CVSS, учитывая, среди прочего, вероятность реализации успешной брутфорс-атаки.

Имхо, ответ на поверхности:

1. CVSS это не священная корова. CVSS это просто опросник. С довольно произвольными полями. С довольно произвольной формулой расчёта скоринга. И сами авторы из First регулярно шатают CVSS только в путь.

2. Сделать свою систему приоритизации уязвимостей не rocket science, а свой пиар-эффект среди ширнармасс оно даёт. Особенно если написать про "внутри у ней нейронка" и про миллион анализируемых параметров.

То, что "систем приоритизации уязвимостей сегодня уже под десяток от разных компаний, организаций и регуляторов" и это "мешает установлению некоего единого языка общения между специалистами" действительно так, не поспоришь. Но это объективная реальность. От призывов, допустим, сплотиться вокруг наступающего CVSS 4.0 она не изменится.

Как мне кажется, нам в России тоже следовало бы отойти от прямого использования CVSS as is в сторону чего-то более практичного и опирающегося на отечественные методические рекомендации, но с возможностью использовать CVSS-векторы в качестве источника данных.

Моя ОСОКА здесь как пример. 😉 Про неё не забываю. После адаптации инфраструктурных метрик понимание как должен выглядеть полный вектор уже есть. Следующей этап - накодить калькулятор.

Александр В. Леонов

Управление Уязвимостями и прочее