Архив за месяц: Июль 2022

А как там в Китае с операционными системами?

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

А как там в Китае с операционными системами? Поискал, почитал. Буду отталкиваться от статьи в TheRegister, но вообще в англоязычном интернете инфы по теме маловато.

1. По данным Statcounter доля Windows на десктопах в Китае в июне 2022 составляет 85%. Это так себе источник конечно, с учётом закрытости китайского Интернета, но доминирование Windows очевидно. Китайские статьи такую же статистику показывают и даже похуже (искать можно по 中国操作系统统计). Во многом ещё потому, что они с 2017 года они внедряли специальную Windows 10 China Government Edition. 🤦🏻‍♂️ Занимательно, что есть большая доля EOL операционок: Windows 7 и даже Windows XP.
2. До недавнего времени попытки перейти на свои ОС выглядели так себе. Был rpm-based проект Red Flag Linux просуществовавший с 1999 по 2014. Был проект Kylin, который просуществовал с 2001 до 2009 на ядре FreeBSD, потом с 2010 до 2013-2015 развивался как NeoKylin на ядре Linux и в конечном итоге свелся к Ubuntu Kylin, который по договору поддерживали Canonical (такое себе замещение ОС получилось 🙂).
3. Но кажется в этом году под это дело дали денег и пошла более активная движуха.
3.1. Перезапустили Red Flag Linux. Теперь на основе openEuler. Что это такое? EulerOS это коммерческий дистрибутив от Huawei. А openEuler это их комьюнити-дистриб. Оба на основе CentOS, но с другим ядром и доработками. Плюс тут ещё накладываются какие-то потенциальные связи openEuler/EulerOS с Huawei openHarmony/HarmonyOS и все становится совсем запутано и загадочно. "Huawei's OpenEuler and HarmonyOS (OpenHarmony) currently share kernel technology. Huawei plans to unify additional components between both OSes."
3.2. Откопали Kylin и запустили проект openKylin. openKylin определяют как "the root community of desktop operating system". В это комьюнити сразу вошли штук 20 компаний. В некоторых статьях пишут, что это будет "Linux Root Distribution", т.е. он не будет основан ни на каких других дистрибутивах, только напрямую на ядре Linux. Прямого подтверждения этого я не увидел, а в википедии на китайском наоборот пишут, что дистриб на основе Ubuntu, но будем посмотреть.
3.3. Есть ещё некоторая суета вокруг дистриба Tongxin UOS, который основывается на дистрибе deepin (поддерживается Ухань-Дипин-Технология), который уже в свою очередь основывается на Debian. Тут я чего-то особенно интересного не увидел, но где-то пишут, что Tongxin UOS тоже может стать "Linux Root Distribution". Ещё и приложеньки из HarmonyOS сможет запускать.
3.4. Есть ещё какой-то совсем загадочный дистриб Zhongke Fangde. Для которого даже официальный сайт не гуглится и статьи на википедии нет. Но пишут, что прям из топ 3.

Некоторые статьи пишут, что в Китае можно насчитать как минимум 15 "отечественных ОС" (что-то напоминает), но в англоязычном интернете о них практически не слышно. В целом, пока не увидел чего-то, что было бы интересно поковырять, тем более использовать на практике. Надеюсь на новости от openKylin, пока эта штука выглядит наиболее перспективно. Если конечно это действительно будет "Linux Root Distribution", а не очередная Ubuntu с нескучными обоями.

На этой неделе много пишут про уязвимости Confluence

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

На этой неделе много пишут про уязвимости Confluence. Их вышло три.

CVE-2022-26136 & CVE-2022-26137: Multiple Servlet Filter vulnerabilities (Authentication bypass, XSS, Cross-origin resource sharing bypass). Много продуктов Atlassian уязвимо. Кроме Confluence и JIRA это ещё и Bitbucket например. Тут все понятно, надо патчить. Ну и в идеале давно пора от этих продуктов отказываться, сами понимаете почему.

CVE-2022-26138: Hardcoded password in Confluence Questions. Эта уязвимость сейчас самая хайповая и забавная. Установка дополнительного аппа Questions для конфлюенса создаёт пользователя disabledsystemuser с захардкоженным паролем. А он не disabled! 🤡 Пароль уже в паблике. Под этим юзером можно читать незащищённые странички доступные confluence-users. Ну не смех ли? 🙂 Исправляется патчингом или блокировкой/удалением пользователя.

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

Посмотрел что новенького появилось в Rapid7 Nexpose/InsightVM в Q2 2022

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

Посмотрел что новенького появилось в Rapid7 Nexpose/InsightVM в Q2 2022. Часть изменений из разряда "а как они вообще без этого раньше жили".

Вот только-только появилась поддержка severity CVSS v3 в дашбордах. Стандарт зарелизили в июне 2015, данные в NVD были с 2017. И вот через 5 лет после этого только решили и эти данные тоже учитывать? Ну, странно.

Или то, что раньше у них были такие странные дашборды по исправлениям, что прогресс по Remediation Project был виден только когда исправления были применены ко всем активам. А теперь стало лучше: "Yes, this means customers no longer have to wait for all the affected assets to be remediated to see progress". Ну круто.

Или вот только-только добавили поддержку AlmaLinux и Rocky Linux. Хотя стабильные версии дистрибутивов появились больше года назад и уже активно используются в энтерпрайзе как замена CentOS. Получается клиенты Rapid7 только сейчас получили возможность их сканировать?

Rapid7 используют термин "recurring coverage" для поддерживаемых систем. И у них есть в паблике список таких систем. "The following software list encompasses those products and services that we are specifically committed to providing ongoing, automated coverage". Не особо, кстати, большой, но круто, что публичный.

С другой стороны, есть и прикольные фичи, как минимум одна. Это Scan Assistant. Фича это была представлена в декабре прошлого года, но сейчас её улучшили. Насколько я понимаю, это что-то вроде агента, который однако не проводит сбора или анализа данных, а только отвечает за аутентификацию сканера. Т.е это решение проблемы использования учеток для сканирования, что всегда адово и рискованно, если утечёт. А так можно раскатать Scan Assistant и сканер будет аутентифицироваться не с помощью учётки хоста, а по сертификатам. "Scan Assistant, a lightweight service deployed on an asset that uses digital certificates for handshake instead of account-based credentials; This alleviates the credential management headaches VM teams often encounter." Вот это прикольная и полезная штука, у других VM вендоров ее не видел. Во втором квартале добавили автоматизацию обновления этого Scan Assistant и ротации сертификатов. Круто, что тема развивается. Но пока только для Windows.

И есть обновления, которые никаких особенных эмоций у меня не вызвали. Это например Asset correlation for Citrix VDI instances или поддержка детекта уязвимостей Oracle E-Business Suite и VMware Horizon. Добавили, ну и хорошо.

Вот тут Palo Alto утверждают занятное: что обычно злоумышленники начинают сканировать периметр организаций на наличие уязвимости через 15 минут после публикации CVE

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

Вот тут Palo Alto утверждают занятное: что обычно злоумышленники начинают сканировать периметр организаций на наличие уязвимости через 15 минут после публикации CVE. Прям вот так:

"The 2022 Attack Surface Management Threat Report found that attackers typically start scanning for vulnerabilities within 15 minutes of a CVE being announced".

Как конкретно эти 15 минут получили вроде нигде не пишут. Но видимо могли засекать на ханипотах/ids попытки эксплуатации каких-то определенных уязвимостей и связали это с датой публикации уязвимости.

Пример приводят, что они через 5 дней после публикации уязвимости выпустили сигнатуру и за 10 часов насобирали две с половиной тысячи попыток эксплуатации.

"For example, Palo Alto Networks released a Threat Prevention signature for the F5 BIG-IP Authentication Bypass Vulnerability (CVE-2022-1388), and within just 10 hours, the signature triggered 2,552 times due to vulnerability scanning and active exploitation attempts".

Круто конечно, но все-таки сигнатуру выпустили далеко не сразу, так что сказать когда именно пошли зловредные сканы начались сложновато.

Но не суть. Не так важно действительно ли через 15 минут сканы начинаются или несколько позже. Факт, что злоумышленники мониторы новостной поток об уязвимостях. И факт, что они мотивированы сканить ваш периметр чаще, использовать для этого нестандартные проверки, а не только те, что есть в вашем коммерческом сканере.

И чтобы безопасникам не играть со злоумышленниками в догонялки единственный вариант это знать и контролировать свой периметр гораздо лучше, чем это может сделать любой внешний исследователь. Понимать зачем тот или иной сервис на периметре нужен. По возможности стараться минимизировать их количество. Если есть какое-то распространенное приложение или сетевое устройство на периметре, то иметь в виду, что их будут целенаправленно искать и ломать. Поэтому для таких сервисов следует отдельно мониторить бюллетени безопасности и начинать реагировать ещё до того как детекты появятся в сканерах и тем более до того как об уязвимости начнут верещать в СМИ.

Сказать-то конечно проще, чем сделать.

Вчера на Anti-Malware вышло интервью c Максимом Бронзинским

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

Вчера на Anti-Malware вышло интервью c Максимом Бронзинским. Он руководитель направления Vulnerability Management платформы Solar MSS. Более чем годное интервью, нерекламное. Я на прошлом двухчасовом эфире на Anti-Malware как раз говорил, что неплохо было бы VM вендорам больше времени уделять методологической работе: как внедрять VM процесс, какие люди должны этим заниматься и как. И вот наметки как раз в эту сторону. Сделал небольшой конспект.

Большая опасность внедрения VM процесса, что он выродится в Vulnerability Assessment. Т.е. с детектированием уязвимостей все будет ок, а до непосредственного исправления уязвимостей не дойдет. Это происходит из-за того, что ИБ с детектированием уязвимостей справляется, а с передачей в IT на исправление нет. Важно встроиться в IT-шные процессы исправления. Для этого нужно общаться с IT, доносить до них информацию об исправлении уязвимостей в наиболее конкретной и доступной форме.

Какие роли/квалификации есть в Vulnerability Management процессе со стороны ИБ:

1. Инженер
- Отвечает за инвентаризацию активов, стремится к максимальному охвату активов VM процессом.
- Правильно настраивает сканирование, стремится к тому, чтобы мы имели полную актуальную информацию об уязвимостях активов.

2. Аналитик
- Описывает, категоризирует, приоритизирует уязвимостей.
- Составляет плана на устранение уязвимостей (собирает несколько мнений, делает вывод на основе экспертности – это сложнее чем выгрузить TOP 50 уязвимостей из сканера).
- Подготавливает отчеты
-- Отчет для Бизнеса отражающий угрозы процессам.
-- Отчет для IT, критерии: понятность, удобность (в т.ч. машиночитаемость), решение о приоритизации.

Рекомендации к внедрению в организации:

- Защищать сразу ТОЛЬКО самые критичные хосты неправильно, пропускаем точки, где злоумышленник может закрепиться.
- Защищать сразу все не получится, т.к. будет слишком сложно добавиться исправления.
- Рекомендуется заходить постепенно, начиная с критических хостов; затем постепенно ужесточать SLA.
- Необходимо отслеживать сколько уязвимостей IT готовы взять в работу (в зависимости от типа уязвимых хостов) с согласованным SLA (в зависимости от типа и критичности уязвимости) и вгружать в IT правильный объем работы.

Рекомендации для продажи VM-процесса бизнесу:

- Бизнесу рекомендуется показать потенциальные потери от успешной атаки в деньгах.
- Можно рассказать, что VM это фундамент ИБ. "Лечить зуб правильнее, чем пить обезболивающее" (например, использовать WAF вместо исправления уязвимости).

Аутсорсить VM можно, но нельзя отдавать функцию принятия решения об исправлении, т.к. из организации это видно всегда лучше.

Думаю как же все-таки нужен professional networking site на замену понятно какому майкрософтовскому

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

Думаю как же все-таки нужен professional networking site на замену понятно какому майкрософтовскому. Чтобы быть полноценной заменой он должен

1. Быть зарегистрированным в адекватною юрисдикции, а не в США. Идеально было бы сейчас в Индии, ОАЭ, Гонконге, Малайзии.
2. Быть направленным на международную кооперацию, а не циклиться на одной стране. Поэтому не подходят чисто китайские или чисто российские площадки, которые даже не заинтересованы в поддержке английской локали.
3. Быть именно профессиональной соцсеточкой, а не просто хостингом для вакансий и резюмешек.

В очередной раз хочется помянуть добрым словом Peerlyst, который хоть и не отвечал всем требованиям, но международное ИБшное комьюнити неплохо так собирал. Чего-то подобного с тех пор (2020) так и не появилось. И кажется абсурдная монополия майкрософтовского сайта так и сохранится, пока мир не начнет всерьез делиться и перегруппировываться во что-то новое. А это скорее всего произойдет не раньше начала активной движухи в Южно-Китайском море.

Как там в "Москва слезам не верит" было: "Человека выдают два обстоятельства: если он неправильно ставит ударения в словах и задает глупые вопросы"

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

Как там в "Москва слезам не верит" было: "Человека выдают два обстоятельства: если он неправильно ставит ударения в словах …> и задает глупые вопросы".

Сегодня я загуглил и узнал, что в слове "report" ударение всегда падает на второй слог, независимо от того, глагол это или существительное и какой это вариант английского. Так-то головой понимаю, что это ДАЛЕКО не единственный косяк в моем английском и всем так-то пофиг, но стыдно атас и хочется сразу все ролики удалить и заново перезаписать. 😅

Самый топ других ошибок, которые все равно у меня иногда проскакивают, это "ва", вместо "ву" в vulnerability (хотя это простительно, т.к. в британском варианте говорят скорее "ва") и ударение на первую "а", вместо второй в слове attacker. 🤦‍♂️🙂