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

Продолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсов

Продолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсов

Продолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсов.

🔹 Почему так много уязвимостей Astra Lin­ux? Upd 0704. В основном это результат собственного ресёрча.
🔹 Для EMIAS OS уязвимости Lin­ux Ker­nel, но даже без ссылки на бюллетень. Откуда именно уязвимость непонятно.
🔹 Откуда уязвимости Win­dows? Их Microsoft выпускали не как CVE-шки, а как ADVi­sories. Потом для них могут добавлять CVE, которые не пробрасываются в БДУ. 🤷‍♂️
🔹 Для уязвимостей Debian Lin­ux аналогично. Они заводятся по бюллетеням DSA без ссылки на CVE на момент публикации. Затем ссылка добавляется, но в БДУ она не пробрасывается. 🤷‍♂️
🔹 Почему много уязвимостей Open Source продуктов? Потому что они заводятся по эксплойтам, в описании которых нет ссылки на CVE.
🔹 Некоторые виндоры не любят заводить CVE идентификаторы. Например, SAP часто выпускают только непубличные SAP Notes.

Принципиальная уязвимость Open Source, которую демонстрирует кейс с бэкдором в XZ Utils, вовсе не техническая

Принципиальная уязвимость Open Source, которую демонстрирует кейс с бэкдором в XZ Utils, вовсе не техническая

Принципиальная уязвимость Open Source, которую демонстрирует кейс с бэкдором в XZ Utils, вовсе не техническая. Она в том, что работа сообществ, отвечающих за написание повсеместно используемого кода, строится на более инфантильных принципах, чем у детишек, которые строят замок в песочнице на детской площадке. За детишками в песочнице хотя бы приглядывают взрослые.

А здесь какие-то гики-бессребреники в каком-то листе рассылки как-то самоорганизауются и решают чудовищно замороченные технические вопросы, которые аффектят сотни миллионов людей. 🤷‍♂️ Кто эти гики, какая у них мотивация, насколько адекватны выбранные ими руководители сообществ? 🤔

Как пишут на Open­NetRu, бэкдор в XZ Utils предположительно внедрил разработчик, который за 2 года постепенно влился в проект, стал его мантейнером и основным контрибьютором. 😎 А предыдущего мантейнера загазлайтили с помощью троллей-виртуалов и он слился. 🤷‍♂️ В итоге бэкдор случайно нашёл сотрудник Microsoft и забил тревогу.

24 марта стартует второй набор онлайн-практикума по Управлению Уязвимостями от Positive Technologies

24 марта стартует второй набор онлайн-практикума по Управлению Уязвимостями от Positive Technologies

24 марта стартует второй набор онлайн-практикума по Управлению Уязвимостями от Pos­i­tive Tech­nolo­gies. Программу существенно расширили и улучшили. Стало вообще круто! 🙂

Я записал для него сегодня 2 новых модуля:

🔹 Построение Vul­ner­a­bil­i­ty Man­age­ment-системы на основе open source и free­ware компонентов. 🆓 Какие инструменты можно использовать для детектировании и приоритизации уязвимостей, а также визуализации состояния инфраструктуры. Какие там есть подводные камни. 🪨

🔹 Сканирование сетевого периметра. От понимания, что такое периметр в организации, к тому, как организовать регулярное сканирование и исправление уязвимостей. 📊

В этот раз читал заранее подготовленный текст с суфлёра, так что должно получиться чётенько. 🙂

➡️ Записывайтесь на практикум, рекомендуйте друзьям.

Здесь ещё официальный пост про него.

Закладка в прошивке светодиодной гирлянды

Закладка в прошивке светодиодной гирлянды

Закладка в прошивке светодиодной гирлянды. Некоторые любители прекрасного любят выставлять у себя из окна светодиодные DIY-гирлянды, на которых можно отображать разнообразные эффекты и надписи. Довольно эффектная штука. Но оказалось, что в прошивке для популярного проекта такой гирлянды была закладка. В полночь 1 января поверх всех эффектов начал отображаться запрещённый в России лозунг. На хозяев одной из украшенных квартир составили протокол о дискредитации ВС РФ.

Как закладка попала в код? Автор проекта пишет на форуме "я не являюсь автором данной прошивки". 🤷‍♂️ Настоящим автором прошивки является человек из сопредельного враждебного государства. Код на наличие закладок толком не проверяли. 🤦‍♂️

Это к слову о контроле над open source кодом и принципе "тысячи глаз". Используя open source код, за которым НЕ стоит внушающая доверие репутация организации или человека, задавайте себе вопрос "а что будет, если туда всё-таки заложили что-то зловредное?"

Три установки после исхода западных вендоров

Три установки после исхода западных вендоров. Предыдущий пост про судьбу специалиста был, разумеется, и про меня тоже. Мне было вполне комфортно работать с западными VM-решениями и писать об этом в своём бложике. Не могу сказать, что исход западных вендоров меня порадовал. Но, с другой стороны, я не был ультрасфокусированным специалистом по Qualys, Ten­able и Microsoft Defend­er, поэтому какой-то катастрофой для меня это не стало. Но заставило призадуматься. В итоге я сформулировал для себя 3 установки, которые выглядят полезными в сложившихся условиях. Возможно они кому-то ещё придутся по вкусу.

1. Специализироваться не на конкретных технических решениях от конкретных вендоров, а на проблеме в целом. Как можно лучше понимать что именно происходит под капотом решений и как, при необходимости, обходиться без них. В контексте нашей темы — как происходит детект уязвимостей в каждой из систем, какие есть тонкости, что и как можно было бы улучшить. Вендоры приходят и уходят, а проблемы остаются.

2. Фокусироваться на Open Source проектах, в особенности на GNU/Linux. Здесь есть несколько моментов:

2.1. Мы во многом утратили или утратим в ближайшем будущем доступ к проприетарным западным решениям. Но вот доступ к Open Source останется, этого у нас никто не отберёт. Несмотря на попытки ограничить возможности контрибьютить код и вести свои проекты, эффективных механизмов препятствовать этому также нет. Поэтому для российского специалиста активная самореализация в Open Source проектах это логичный путь для приобретения скиллов актуальных в общемировом масштабе.

2.2. Open Source это основа российского импортозамещения. Практически все российские ОС это Lin­ux, отечественных IT/ИБ продуктов без использования открытых библиотек также не бывает. Можно долго спорить на тему оправдано ли называть отечественным то, что в основном разрабатывается где-то в Калифорнии. Имхо, это довольно скверно, но может быть в какой-то степени скомпенсировано вовлечённостью в эти проекты российских специалистов как со стороны разработки, так и со стороны использования. Безусловно история успеха здесь проект Post­greSQL. Если появятся эффективные центры компетенций по ключевым открытым компонентам, то возможно появятся и шансы "перевернуть игру", и уже в США будут переживать по поводу российская влияния на Open Source. А если не появятся, хотя бы несколько снизим свои риски в процессе. 😉

3. Относиться к российским коммерческим решениям с "презумпцией крутости". Если не доказано, что продукт полностью неработоспособен и это явное мошенничество, считать российский продукт крутым. 🙂 Я не согласен с бесконечной критикой российских продуктов, что они стоят дороже и при этом менее функциональны. Вернее да, это так, они действительно часто дороже и менее функциональны. 😅 Но критиковать их за это также бессмысленно как возмущаться тем, что за летом приходит зима. Здесь сошлюсь на уморительный пост Рустэма Хайретдинова про первое свидание и сальто назад на коньках. 😆 Наши вендоры зачастую стартуют с нуля, имея в сотни и тысячи раз меньше ресурсов, чем западные. У них нет возможности демпинговать и работать на перспективу, им нужно выживать и развиваться здесь и сейчас. И при этом они умудряются производить что-то сопоставимое с западными решениями. Это ли не чудо! В целом, считаю, что нам к российским ИБ-вендорам, особенно к стартапам, нужно относиться как в Израиле относятся к своим. Холить, лелеять, гордиться, нахваливать и оказывать всяческое содействие. Ну возможно делать это чуть менее энергично, все же у нас несколько иная стилистика. Но ни в коем случае не хаить их за то, что они не top-notch за копейки.

Зарелизил на неделе утилитку imgtov, с помощью которой свои видяшки собираю, как и обещал ранее

Зарелизил на неделе утилитку img­tov, с помощью которой свои видяшки собираю, как и обещал ранее. Последнюю видяшку собрал аж в 8k качестве, вроде норм на Youtube и VK залилось.

Название это абберевиатура от "images to video". Кроме того "tov" это "хорошо" на иврите ("טוב"). И это хорошо. 🙂

Сделал максимально примитивно. В input.txt кладем таймстемпы. Исходные файлы с картинками кладем в директорию images. В корень кладем input.mp3. Запускаем imgtov.py. Получаем video.mp4, радуемся. Подробнее читайте в описании проекта на гите.

Если вдруг кому-то ещё такое надо, пользуйтесь!

У Алексея Лукацкого сегодня был интересный пост про "H.R.7900 — National Defense Authorization Act for Fiscal Year 2023"

У Алексея Лукацкого сегодня был интересный пост про "H.R.7900 — Nation­al Defense Autho­riza­tion Act for Fis­cal Year 2023". Длиннющий документ. Местами видимо интересный. Если в PDF выгружать, то там 3854 страницы. Слово "Rus­sia" там встречается 281 раз. Солидно. 🙂 "Chi­na" только 130 раз.

Алексей Викторович обратил внимание, что теперь согласно "SEC. 6722. DHS SOFTWARE SUPPLY CHAIN RISK MANAGEMENT." контракторам Depart­ment of Home­land Secu­ri­ty (DHS) придется собирать зависимости их продуктов в "bill of mate­ri­als" и доказывать сертификатом, что ни в одной из зависимостей нет ни одной уязвимости из NVD. Не то, что там критичных уязвимостей нет, а вообще никаких CVE нет!

Практика занимательная. Учитывая с какой скоростью выходят новые уязвимости это получается, что по-хорошему нужно будет постоянно пересобирать продукт и тестить, что ничего не разъехалось, чтобы к моменту сертификации быть максимально свеженькиими и неуязвимыми. Сомневаюсь, что кто-то реально сможет честно пройти такую сертификацию буквально так, как это написано. Но если да, было бы интересно посмотреть на этих монстров разработки, тестирования и автоматизации. 🙂 Хотя по сути так было бы правильно.

Ну и там вроде не конкретизировано кто и как именно должен процедуру сертификации проводить, так что могут быть нюансы. 😏

Но меня больше зацепило, что там речь идет не только об NVD, но и

"(B) any data­base des­ig­nat­ed by the Under Sec­re­tary, in coor­di­na­tion with the Direc­tor of the Cyber­se­cu­ri­ty and Infra­struc­ture Secu­ri­ty Agency, that tracks secu­ri­ty vul­ner­a­bil­i­ties and defects in open source or third-par­ty devel­oped soft­ware."

Это что такое? Это просто вставочка на будущее, типа вдруг когда-нибудь сделают ещё какую-нибудь базу? Или есть какая-то ещё база уязвимостей Open Source софта разработанная DHS и CISA, которая не в паблике? Загадочно. 🙂

PS: Надо бы тамошним законодателям рассказать, что у каждого item в "bill of mate­ri­als" могут быть свои зависимости, и в этих зависимостях могут быть (и есть) уязвимости, а для самого item‑а в NVD об этом никакой информации не будет. Как не было отдельной CVE под каждый софт уязвимый Log4Shell. Даешь "bill of mate­ri­als" для каждого item‑а и тотальный разбор этой адской матрешки! Муа-ха-ха! 😈