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

С чего бы количеству новых уязвимостей уменьшаться, если код не становится лучше?

С чего бы количеству новых уязвимостей уменьшаться, если код не становится лучше?

С чего бы количеству новых уязвимостей уменьшаться, если код не становится лучше? Даже Майкрософт с их образцовой системой выявления и исправления уязвимостей (без шуток, в этом они top-notch) и минимизацией использования чужого кода практически каждый месяц исправляет больше сотни уязвимостей в своих продуктах. Откуда-то ведь они берутся? Кто-то лепит эти баги, уходящие беспрепятственно в прод? Учитывая лаг в месяцы между тем как исследователь сообщает об уязвимости в Microsoft и, собственно, датой выхода фикса, известных незакрытых уязвимостей в бэклоге у MS должно быть очень и очень много.

Что уж говорить о компаниях попроще, продающих под видом своих продуктов сплошной суп из за… заимствованного опенсурсного кода. 🙂 Который зачастую разрабатывает полусумасшедший мейнтейнер-энтузиаст на пару с очередным фейковым Jia Tan-ом. 😈 Это они, должны требования по безопасной разработке выполнять, чтобы не допускать уязвимостей? Ну да, конечно, ждите-ждите. 😏

Прочитал статью в блоге US Council on Foreign Relations (CFR) про импортозамещение в России и Astra Linux

Прочитал статью в блоге US Council on Foreign Relations (CFR) про импортозамещение в России и Astra Linux

Прочитал статью в блоге US Council on Foreign Relations (CFR) про импортозамещение в России и Astra Linux. Ссылку давать не буду. Статья довольно дурацкая и с ошибками типа вендора смартфонов "Xiamoi". 😅 Но настроения на Западе передаёт. 😉

Их основные идеи:

🔹 Русские зависят от китайских технологий. Нужно раздувать опасности, которые им это несёт, чтобы вбить клин между русскими и китайцами.
🔹 Нужно исследовать Astra Linux. Наверняка у русских ограничены возможности в области тестирования безопасности кода. США и союзники могут это использовать "to press the advantage in cyberspace".

Отсюда три вывода:

🔻 Импортозамещение - это круто, правильно и беспокоит потенциального противника. 👍
🔻 Open Source - это арена противостояния государств. Нужно вкладываться в средства контроля кода и уменьшать зависимость от сомнительных апстримов. Горячий привет российским переупаковщикам RHEL-а.
🔻 В игру с воздействием на апстримы могут играть двое. 😉 См. кейс с XZ Utils.

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

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

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

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

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

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

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

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

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

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

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

24 марта стартует второй набор онлайн-практикума по Управлению Уязвимостями от Positive Technologies. Программу существенно расширили и улучшили. Стало вообще круто! 🙂

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

🔹 Построение Vulnerability Management-системы на основе open source и freeware компонентов. 🆓 Какие инструменты можно использовать для детектировании и приоритизации уязвимостей, а также визуализации состояния инфраструктуры. Какие там есть подводные камни. 🪨

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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