Дмитрий Галов, «Лаборатория Касперского»: Со стороны организаций, которые внедряют у себя open-source решения, требуется тщательная проверка документации изменений в коде

erid: 2SDnjchA7sG
Дмитрий Галов, «Лаборатория Касперского»: Со стороны организаций, которые внедряют у себя open-source решения, требуется тщательная проверка документации изменений в коде
Дмитрий Галов, «Лаборатория Касперского»: Со стороны организаций, которые внедряют у себя open-source решения, требуется тщательная проверка документации изменений в коде
11.06.2024

Руководитель Российского исследовательского центра «Лаборатории Касперского» Дмитрий Галов рассказал порталу Cyber Media о специфике opensource-проектов с точки зрения кибербезопасности, проблемных точках и вызовах, а также о том, как безопасно интегрировать свободное ПО в свою инфраструктуру.

Cyber Media: В недавней истории с xz-бэкдором интересен тот факт, что он незамеченным попал в мартовские сборки многих дистрибутивов, от Kali до Debian. Как это возможно в принципе и что делают владельцы open-source-проектов, чтобы минимизировать риски попадания уязвимых компонентов?

Дмитрий Галов: XZ – это утилита для сжатия данных, интегрированная во многие популярные дистрибутивы Linux. Особая опасность бэкдорной библиотеки заключается в ее использовании серверным процессом OpenSSH sshd. Существование данного бэкдора в системе малозаметно. До тех пор, пока он не будет активирован злоумышленниками по сети, проявления будут минимальны – например, незначительно увеличится время подключения по протоколу SSH.

В нескольких дистрибутивах на базе systemd, включая Ubuntu, Debian и RedHat / Fedora Linux, процесс OpenSSH исправлен для использования функций systemd и, как следствие, зависит от этой библиотеки. Конечной целью злоумышленников, скорее всего, было внедрение в sshd возможности удаленного выполнения кода, которую больше никто не мог использовать. При этом пакет появился еще в неоттестированных версиях. Они не используются обычными корпоративными пользователями.

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

Open-source сообщество пытается следить за появлением подобных рисков. Так, данный бэкдор был замечен из-за того, что один из пользователей обратил внимание, что его сервера стали потреблять намного больше процессорного времени, и он начал выяснять, в чем дело. Специалисты по кибербезопасности регулярно проводят исследования для поиска уязвимостей и вредоносных закладок в open-source ПО, о чем своевременно уведомляют своих пользователей и сообщество.

Cyber Media: Подробности появления xz-бэкдора похожи на шпионский детектив: «нейтрализация» прошлого контрибьютора из-за проблем с ментальным здоровьем, передача прав никому неизвестному человеку, внедрение бэкдора и т.д. Как вообще выглядит процесс разработки open-source-проектов (зрелых и массово используемых), и насколько, на ваш взгляд, легко их скомпрометировать?

Дмитрий Галов: Внутри Linux есть «пакеты», в частности, библиотека LZMA, которая используется для удаленного управления серверами. У «пакетов» есть добровольцы-«мейнтейнеры», те, кто вносят правки и улучшают, дорабатывают их. В 2022 году появился энтузиаст, который развивал пакет с этой библиотекой, а в феврале 2024 года в пакете появилась «закладка» с незадокументированной возможностью. Предполагалось, что дальше это распространится на все популярные дистрибутивы Linux, такие как Debian. Если бы «закладка» попала в дистрибутивы, злоумышленник смог бы получать доступ на сервера в интернете просто используя эту незадокументированную возможность. Это и сервера внутри организаций, и вебсайты, и большие ЦОДы. Linux используется во всех областях облачных вычислений.

Очевидно, что этот бэкдор очень сложен и использует изощренные методы, позволяющие избежать обнаружения. К ним относится многоступенчатая имплантация в репозиторий XZ, а также сложный код, содержащийся в самом бинарном файле. За последние годы это первая настолько крупная атака. Появляется недоверие к open-source пакетам, и все задаются вопросом, как проверять open-source, чтобы избежать последствий. Никто не застрахован, что в других пакетах нет закладок. При этом в основную массу дистрибутивов «закладка» попасть не успела. Благодаря тому, что нашли ее очень быстро, большого воздействия на Linux-системы не произошло.

В других репозиториях open-source пакетов – Python, Node JS – закладки встречаются постоянно, но обычно они не привлекают внимания. Данная же атака затронула одно из самых популярных приложений, SSH, и сообщество обратило на нее внимание.

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

Cyber Media: Какие меры, по-вашему мнению, могли бы предотвратить появление закладок в open-source-проектах? В чем сложность реализации этих мер?

Дмитрий Галов: Полностью предотвратить такой риск не выйдет, но можно его минимизировать. Код как правило рецензируется несколькими участниками, и кто-то из них может выявить подозрительные изменения: активное-opensource сообщество может выявить действия злоумышленников. Автоматизированные инструменты анализа кода могут помочь в решении этой задачи. Со стороны организаций, которые потом внедряют у себя open-source решения, требуется тщательная проверка документации изменений в коде.

Cyber Media: Какие принципы и практики компания должна соблюдать, чтобы обеспечить информационную безопасность при использовании open-source-проектов?

Дмитрий Галов: С помощью соответствующих решений всегда можно понять, что с системой что-то не так. Для любых систем – и open-source, и нет – нужна комплексная защита: не только обнаружение, сканирование, но и оценка всего поведения системы специальными решениями по кибербезопасности.

Защититься от таких атак сложно, но возможно. Как я уже упоминал, рекомендуем использовать в критичных системах только стабильные Linux-дистрибутивы, которые уже «отлежались» и были проверены многими пользователями и компаниями. В критической инфраструктуре нужно не только проверять все компоненты обновления перед самим обновлением системы, но и затем отслеживать, как ведет себя система после обновления.

Cyber Media: Можно ли сказать, что уровень безопасности open-source-проектов всегда ниже, чем у вендоров? Если учесть, что злоумышленники могут участвовать как в открытых проектах, так и проникать в компании?

Дмитрий Галов: Уровень безопасности open-source проектов не обязательно ниже, чем у проприетарных решений от вендоров. Например, в каком-то случае активное opensource-сообщество может быстро обнаружить и устранить уязвимости, в то время как в проприетарных системах аудит часто ограничен внутренней командой. При этом вендоры часто имеют больше ресурсов, могут запускать баг-баунти программы.

Важно анализировать безопасность каждого решения, каждой сборки отдельно и принимать соответствующие меры. Уровень безопасности определяется конкретными мерами и усилиями, предпринятыми для защиты проекта.

Cyber Media: Каким вы видите буду будущее open-source-проектов? Стоит ли ожидать, что появившиеся за многие годы проблемные точки, такие как внедрение незадекларированных возможностей, бэкдоров и т.д. будут как-то решаться?

Дмитрий Галов: «Закладки» могут находить как opensource-продуктах, так и в проприетарном ПО, поэтому, на наш взгляд, данный инцидент не повлияет на рынок open-source. Благодаря тому, что «закладка» нашлась быстро, тяжелых последствий удалось избежать. Мы не знаем о серьезных взломах из-за этого бэкдора. Однако, если бы ее сейчас не обнаружили, через несколько месяцев она бы попала в основные дистрибутивы Linux.

Cyber Media: Дайте рекомендации компаниям, которые используют open-source в своей инфраструктуре, как безопасно выстроить патч-менеджмент таких компонентов?

Дмитрий Галов: Ведите мониторинг уязвимостей, подпишитесь на уведомления о новых уязвимостях через базы данных и специальные сервисы – например, «Лаборатория Касперского» предоставляет такую информацию в рамках Kaspersky Threat Intelligence. Тестируйте компоненты перед развертыванием, используйте проверенные сообществом сборки. Обучайте сотрудников киберграмотности, а сотрудников отделов ИБ – принципам безопасного использования и обновления компонентов. Обязательно создавайте резервные копии данных организации и пользователей. Также рекомендую регулярно проводить ИБ-аудиты, использовать для анализа угроз вашей инфраструктуре сервисы MDR (Managed Detection & Response) – так внешние эксперты смогут оказать вам помощь.

Популярные материалы

Комментарии 0