Открытый источник вредоносных программ

Количество инцидентов с закладками в программах стремительно выросло за последние несколько месяцев. Причем «заминированные» таким образом open source решения специально нацелены на пользователей из России или Белоруссии. Для этого может применяться IP-адрес или локаль (региональные настройки), которые позволяют идентифицировать пользователей из определенного региона мира. Разумеется, этот метод не может считаться стопроцентно точным.

Одним из самых громких случаев такого рода было обновление пакета для межпроцессного взаимодействия node-ipc, которое затирало содержимое файлов, приводя к существенным потерям важных данных.

В России общее количество вредоносных закладок в программных продуктах с открытым кодом с февраля 2022 г. увеличилось в 15–20 раз. Причем если ранее атаки такого рода в основном совершались киберпреступниками, то сейчас авторами вредоносного кода являются легитимные программисты – авторы кода.

Всплеск активности и многообразия

По данным «Лаборатории Касперского», сегодня можно найти до 100 различных вредоносных закладок в зарубежном открытом ПО в общедоступных репозиториях.

Самые уязвимые категории – домашние пользователи и СМБ-компании, поскольку они часто не имеют желания или навыков для просмотра программных обновлений на предмет неприятных сюрпризов от разработчиков. Пострадали и айтишники: к примеру, были изменены Python-пакет ctx и PHP-пакет phppass – в них встроили функции воровства ключей для работы с облаком AWS.

В целом спектр возможных проблем от использования подобного испорченного софта ничем не ограничен – все зависит от целей создателей закладок. Чаще всего это перехват контроля над IT-системами и данными пользователей, блокировка работы компании, хищение информации или ее уничтожение без возможности восстановления.

Паниковать не нужно – в настоящий момент, несмотря на всю серьезность ситуации, больше проблем для российского бизнеса и IT-отрасли доставил отказ в лицензиях и обслуживании со стороны западных сервисов и вендоров. Но и игнорировать проблему было бы недопустимым легкомыслием.

Плюс ситуации

Волна open source инцидентов пока что не стихает. По логике она должна пойти на спад одновременно с изменением геополитической ситуации, но до тех пор все подобные риски необходимо считать высокоприоритетными.

С другой стороны, всплеск таких ИБ-инцидентов может изменить подход бизнеса к использованию компонентов или готовых решений с открытым кодом.

Новости о закладках периодически курсируют по IT-сообществу с начала 2000-х гг. Например, были утверждения о попытках модифицировать ядро Linux или изменить протоколы IPsec в открытой ОС OpenBSD со стороны ФБР США. Однако эти истории, как правило, оставались на уровне администраторов.

Нынешняя же ситуация с намеренными вредоносными функциями из-за масштабов, частоты и освещения в СМИ попала на глаза акционерам и владельцам компаний. Они явно не намерены оставлять проблему без внимания. Нельзя сказать, что произошла полная дискредитация идеологии и продуктов open source, но отношение бизнеса к ним определенно поменялось.

Основы open source безопасности

В классической разработке IT-решения своими силами важным моментом в профилактике инцидентов с закладками является разделение жизненного цикла продукта на пять стадий: планирование, дизайн, разработка, тестирование и запуск в эксплуатацию.

Это защита на уровне технических и организационных мер: к примеру, на этапе разработки ошибки или намеренное внесение небезопасных функций зачастую не приводят к уязвимостям, потому что далее код проходит анализ и тестирование продукта и его безопасности. Только после выявления и удаления всех багов и уязвимостей он разворачивается в продуктивной среде. В случае open source важнейшую роль играют на этом рубеже защиты команда разработки (сообщество) и исследователи безопасности.

При таком подходе вероятность создания закладки разработчиком-злоумышленником существенно снижается – в том числе за счет невозможности обойти объективный контроль коллег: иначе придется вовлекать в сговор и их.

В open source код пишется сообществом, однако второй и третий этапы контроля вполне реализуемы на стороне компаний: стандартные процедуры профилактики такого рода угроз в открытом ПО как минимум должны включать в себя тщательное ревью кода после обновлений и тестирование сборок в безопасной среде.

То есть в IT-ландшафте компании должен быть выделенный участок, где запуск обновленного кода в случае каких-то проблем не повлияет на работу продуктивной части.

Второй рабочий метод для гарантий безопасности в отношении open source, который также реализуется силами IT-службы компании, – технический. Это прогон кода и его сборки через средства статического анализа (SAST) и динамического тестирования (DAST), которые активно применяются в методологии безопасной IT-разработки.

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

Перспектива

Самый главный момент – надеяться на сообщество в таких критичных для существования бизнеса областях, как софт, нельзя. Сообщество или эксперты могут не заметить закладки, также специалисты могут быть ангажированными.

Поэтому угроза должна контролироваться на уровне компании. Возможно, в ближайшем будущем это приведет к некоей деглобализации open source сообщества с разделением на сегменты – российский, китайский, европейский и т. п. Например, Минцифры России заявило о планах по созданию в стране условий для публикации софтверных разработок под открытой лицензией в целях свободного использования, модификации и распространения.