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

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

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

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

1. По данным Stat­counter доля Win­dows на десктопах в Китае в июне 2022 составляет 85%. Это так себе источник конечно, с учётом закрытости китайского Интернета, но доминирование Win­dows очевидно. Китайские статьи такую же статистику показывают и даже похуже (искать можно по 中国操作系统统计). Во многом ещё потому, что они с 2017 года они внедряли специальную Win­dows 10 Chi­na Gov­ern­ment Edi­tion. 🤦🏻‍♂️ Занимательно, что есть большая доля EOL операционок: Win­dows 7 и даже Win­dows XP.
2. До недавнего времени попытки перейти на свои ОС выглядели так себе. Был rpm-based проект Red Flag Lin­ux просуществовавший с 1999 по 2014. Был проект Kylin, который просуществовал с 2001 до 2009 на ядре FreeB­SD, потом с 2010 до 2013–2015 развивался как NeoKylin на ядре Lin­ux и в конечном итоге свелся к Ubun­tu Kylin, который по договору поддерживали Canon­i­cal (такое себе замещение ОС получилось 🙂).
3. Но кажется в этом году под это дело дали денег и пошла более активная движуха.
3.1. Перезапустили Red Flag Lin­ux. Теперь на основе openEuler. Что это такое? EulerOS это коммерческий дистрибутив от Huawei. А openEuler это их комьюнити-дистриб. Оба на основе Cen­tOS, но с другим ядром и доработками. Плюс тут ещё накладываются какие-то потенциальные связи openEuler/EulerOS с Huawei openHarmony/HarmonyOS и все становится совсем запутано и загадочно. "Huawei's OpenEuler and Har­monyOS (Open­Har­mo­ny) cur­rent­ly share ker­nel tech­nol­o­gy. Huawei plans to uni­fy addi­tion­al com­po­nents between both OSes."
3.2. Откопали Kylin и запустили проект openKylin. openKylin определяют как "the root com­mu­ni­ty of desk­top oper­at­ing sys­tem". В это комьюнити сразу вошли штук 20 компаний. В некоторых статьях пишут, что это будет "Lin­ux Root Dis­tri­b­u­tion", т.е. он не будет основан ни на каких других дистрибутивах, только напрямую на ядре Lin­ux. Прямого подтверждения этого я не увидел, а в википедии на китайском наоборот пишут, что дистриб на основе Ubun­tu, но будем посмотреть.
3.3. Есть ещё некоторая суета вокруг дистриба Tongx­in UOS, который основывается на дистрибе deepin (поддерживается Ухань-Дипин-Технология), который уже в свою очередь основывается на Debian. Тут я чего-то особенно интересного не увидел, но где-то пишут, что Tongx­in UOS тоже может стать "Lin­ux Root Dis­tri­b­u­tion". Ещё и приложеньки из Har­monyOS сможет запускать.
3.4. Есть ещё какой-то совсем загадочный дистриб Zhongke Fangde. Для которого даже официальный сайт не гуглится и статьи на википедии нет. Но пишут, что прям из топ 3.

Некоторые статьи пишут, что в Китае можно насчитать как минимум 15 "отечественных ОС" (что-то напоминает), но в англоязычном интернете о них практически не слышно. В целом, пока не увидел чего-то, что было бы интересно поковырять, тем более использовать на практике. Надеюсь на новости от openKylin, пока эта штука выглядит наиболее перспективно. Если конечно это действительно будет "Lin­ux Root Dis­tri­b­u­tion", а не очередная Ubun­tu с нескучными обоями.

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

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

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

CVE-2022–26136 & CVE-2022–26137: Mul­ti­ple Servlet Fil­ter vul­ner­a­bil­i­ties (Authen­ti­ca­tion bypass, XSS, Cross-ori­gin resource shar­ing bypass). Много продуктов Atlass­ian уязвимо. Кроме Con­flu­ence и JIRA это ещё и Bit­buck­et например. Тут все понятно, надо патчить. Ну и в идеале давно пора от этих продуктов отказываться, сами понимаете почему.

CVE-2022–26138: Hard­cod­ed pass­word in Con­flu­ence Ques­tions. Эта уязвимость сейчас самая хайповая и забавная. Установка дополнительного аппа Ques­tions для конфлюенса создаёт пользователя dis­abledsys­te­muser с захардкоженным паролем. А он не dis­abled! 🤡 Пароль уже в паблике. Под этим юзером можно читать незащищённые странички доступные con­flu­ence-users. Ну не смех ли? 🙂 Исправляется патчингом или блокировкой/удалением пользователя.

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

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

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

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

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

Или то, что раньше у них были такие странные дашборды по исправлениям, что прогресс по Reme­di­a­tion Project был виден только когда исправления были применены ко всем активам. А теперь стало лучше: "Yes, this means cus­tomers no longer have to wait for all the affect­ed assets to be reme­di­at­ed to see progress". Ну круто.

Или вот только-только добавили поддержку Alma­L­in­ux и Rocky Lin­ux. Хотя стабильные версии дистрибутивов появились больше года назад и уже активно используются в энтерпрайзе как замена Cen­tOS. Получается клиенты Rapid7 только сейчас получили возможность их сканировать?

Rapid7 используют термин "recur­ring cov­er­age" для поддерживаемых систем. И у них есть в паблике список таких систем. "The fol­low­ing soft­ware list encom­pass­es those prod­ucts and ser­vices that we are specif­i­cal­ly com­mit­ted to pro­vid­ing ongo­ing, auto­mat­ed cov­er­age". Не особо, кстати, большой, но круто, что публичный.

С другой стороны, есть и прикольные фичи, как минимум одна. Это Scan Assis­tant. Фича это была представлена в декабре прошлого года, но сейчас её улучшили. Насколько я понимаю, это что-то вроде агента, который однако не проводит сбора или анализа данных, а только отвечает за аутентификацию сканера. Т.е это решение проблемы использования учеток для сканирования, что всегда адово и рискованно, если утечёт. А так можно раскатать Scan Assis­tant и сканер будет аутентифицироваться не с помощью учётки хоста, а по сертификатам. "Scan Assis­tant, a light­weight ser­vice deployed on an asset that uses dig­i­tal cer­tifi­cates for hand­shake instead of account-based cre­den­tials; This alle­vi­ates the cre­den­tial man­age­ment headaches VM teams often encounter." Вот это прикольная и полезная штука, у других VM вендоров ее не видел. Во втором квартале добавили автоматизацию обновления этого Scan Assis­tant и ротации сертификатов. Круто, что тема развивается. Но пока только для Win­dows.

И есть обновления, которые никаких особенных эмоций у меня не вызвали. Это например Asset cor­re­la­tion for Cit­rix VDI instances или поддержка детекта уязвимостей Ora­cle E‑Business Suite и VMware Hori­zon. Добавили, ну и хорошо.

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

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

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

"The 2022 Attack Sur­face Man­age­ment Threat Report found that attack­ers typ­i­cal­ly start scan­ning for vul­ner­a­bil­i­ties with­in 15 min­utes of a CVE being announced".

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

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

"For exam­ple, Palo Alto Net­works released a Threat Pre­ven­tion sig­na­ture for the F5 BIG-IP Authen­ti­ca­tion Bypass Vul­ner­a­bil­i­ty (CVE-2022–1388), and with­in just 10 hours, the sig­na­ture trig­gered 2,552 times due to vul­ner­a­bil­i­ty scan­ning and active exploita­tion attempts".

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

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

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

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

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

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

Вчера на Anti-Mal­ware вышло интервью c Максимом Бронзинским. Он руководитель направления Vul­ner­a­bil­i­ty Man­age­ment платформы Solar MSS. Более чем годное интервью, нерекламное. Я на прошлом двухчасовом эфире на Anti-Mal­ware как раз говорил, что неплохо было бы VM вендорам больше времени уделять методологической работе: как внедрять VM процесс, какие люди должны этим заниматься и как. И вот наметки как раз в эту сторону. Сделал небольшой конспект.

Большая опасность внедрения VM процесса, что он выродится в Vul­ner­a­bil­i­ty Assess­ment. Т.е. с детектированием уязвимостей все будет ок, а до непосредственного исправления уязвимостей не дойдет. Это происходит из-за того, что ИБ с детектированием уязвимостей справляется, а с передачей в IT на исправление нет. Важно встроиться в IT-шные процессы исправления. Для этого нужно общаться с IT, доносить до них информацию об исправлении уязвимостей в наиболее конкретной и доступной форме.

Какие роли/квалификации есть в Vul­ner­a­bil­i­ty Man­age­ment процессе со стороны ИБ:

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

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

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

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

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

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

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

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

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

Думаю как же все-таки нужен pro­fes­sion­al net­work­ing site на замену понятно какому майкрософтовскому. Чтобы быть полноценной заменой он должен

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

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

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

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

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

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

Самый топ других ошибок, которые все равно у меня иногда проскакивают, это "ва", вместо "ву" в vul­ner­a­bil­i­ty (хотя это простительно, т.к. в британском варианте говорят скорее "ва") и ударение на первую "а", вместо второй в слове attack­er. 🤦‍♂️🙂