Открытый и опасный: как снизить риски open source в приложениях

Владимир Высоцкий

Руководитель развития бизнеса ПО Solar appScreener

Как отмечают рыночные аналитики, более 80% российских компаний используют в разработке компоненты открытого исходного кода (open source software, OSS). Основные мотивы – экономия и возможность кастомизации. Сторонние компоненты, библиотеки и фреймворки позволяют существенно ускорить процесс разработки, обеспечивая высокую производительность и минимизируя трудозатраты.

Однако такие компоненты зачастую выступают источником потенциальных уязвимостей, в том числе транзитивных зависимостей, и могут привести к серьезным проблемам в сфере безопасности софтверных продуктов, если их использовать бесконтрольно и без проверки. Специально для Cyber Media руководитель развития бизнеса ПО Solar appScreener Владимир Высоцкий поделился опытом практики по разработке безопасных приложений и тем, с какими ключевыми проблемами могут столкнуться IT-команды.

Контроль за кодом сторонних библиотек

В отличие от собственного кода, сторонние компоненты не всегда поддаются полноценному контролю. Программисты не всегда могут быть уверены, что в сторонней библиотеке нет вредоноса или скрытых уязвимостей, которые могут быть использованы злоумышленниками. Показательный пример — добавление в открытый код вредоносной функциональности, которая активируется только в российском киберпространстве. Так, российские эксперты в 2022 году выявили компонент в пакете, который должен был улучшать производительность и функциональность кода на JavaScript. Но вместо этого он выводил на экран политические лозунги, если запускался в тайм-зоне России или Белоруссии.

Также в бесплатных библиотеках может содержаться уязвимость Log4Shell, которая позволяет подключаться к компьютеру пользователя и передавать конфиденциальную информацию (персональные данные, пароли и т. п.). Это в свою очередь создает риски в клиентских финтех-, банковских и e-commerce-приложениях.

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

Следующий риск – это устаревшие версии библиотек

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

Характерные уязвимости для открытого исходного кода

Уязвимость в Log4j

Одним из самых ярких примеров угроз, связанных с использованием сторонних компонентов, является уязвимость в популярной библиотеке для логирования Log4j. В декабре 2021 года было обнаружено, что библиотека содержит уязвимость (CVE-2021-44228), которая позволяет атакующим выполнять произвольный код на сервере, что открывает дверь для целевых атак. Уязвимость имела высокий уровень опасности, так как она затрагивала огромное количество приложений, использующих эту библиотеку.

Как злоумышленники могли воспользоваться этой уязвимостью? Они могли отправить специальную строку через HTTP-запросы, которая бы инициировала выполнение произвольного кода на сервере. Это могло привести к удаленному исполнению кода и полному компрометированию системы. Важно отметить, что для эксплуатации этой уязвимости не требовалось специальных привилегий, а сама уязвимость касалась всех версий Log4j от 2.0 до 2.14.1.

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

Второй пример – это атака на цепочку поставок, которая была реализована через «отравление» библиотеки Xz-утилит. Xz-utils широко используются в дистрибутивах Linux, включая Debian и Red Hat. В 2022 году злоумышленники смогли получить контроль над репозиторием, в который были добавлены две версии утилит (5.6.0 и 5.6.1) со встроенным бэкдором. Бэкдор находился в коде, которые отвечает за компрессию и декомпрессию данных по алгоритму Izma. Этот код используется множеством программ и утилит в составе дистрибутивов Linux, к нему также обращается сервер OpenSSH. Таким образом создается ситуация, когда неавторизованный пользователь подключается по протоколу SSH, передает специфический ключ, который и активирует бэкдор. Атакующий через выполнение произвольного кода таким образом получает полный контроль над уязвимой системой.

Бэкдор пытались внедрить «под прикрытием»: необходимый для его работы код присутствовал только в архивах исходников, которые используют мейнтейнеры дистрибутивов. Атаки практически удалась: вредоносный код попал в бета-версию дистрибутивов Fedora 40, Kali Linux, присутствовал в тестовой ветке Debian. По оценке экспертов, в зоне риска оказались до 2 млн хостов. Распространение бэкдора остановил сотрудник Microsoft, проводивший тестирование производительности и случайно выявил длительное подвисание процесса liblzma, к которому обращался демон sshd.

Уязвимость в OpenSSL

Ещё один важный пример касается уязвимости в OpenSSL — широко используемой криптографической библиотеке, которая обеспечивает безопасное подключение в интернете (например, через протоколы HTTPS). В версии OpenSSL 1.0.1 была обнаружена уязвимость, получившая название Heartbleed. Эта уязвимость позволяла атакующему извлечь из памяти серверов секретные ключи и другие конфиденциальные данные, что могло привести к краже личной информации и данных, передаваемых по защищенному каналу.

В случае с Heartbleed безопасность была нарушена из-за ошибки в реализации протокола SSL/TLS. Атака происходила на уровне буферов данных, где злоумышленники могли запросить возврат произвольного объема памяти и получить данные, которые могли быть в ней размещены.

Для предотвращения подобных инцидентов необходимо следить за актуальностью версий OpenSSL, регулярно обновлять библиотеки и внимательно относиться к выбору компонент, которые обеспечивают критическую безопасность.

Уязвимости open sourсe для разработки и развертывания ML-моделей

Например, CVE-2021-41228 — уязвимость в TensorFlow, позволяющая злоумышленникам выполнить произвольный код через утилиту saved_model_cli при обработке данных через параметр --input_examples. Проблема возникала из-за использования небезопасной функции eval для обработки внешних данных, что позволяло атакующему внедрить вредоносный код, который выполнялся на машине пользователя. Уязвимость была исправлена в версиях TensorFlow 2.7.0, 2.6.1, 2.5.2 и 2.4.4, где eval был заменён на более безопасные методы обработки входных данных.

Использование опенсорсных решений для разработки и развертывания ML-моделей, таких, как TensorFlow, предоставляет много плюсов, но важно помнить, что безопасность всегда должна быть в приоритете. Для этого используются SCA инструменты.

Минимизируем риски при использовании сторонних компонентов

Чтобы снизить риски, связанные с использованием сторонних компонентов, необходимо применять ряд технических практик и инструментов.

Инструменты для автоматизированного анализа уязвимостей

Современные инструменты для анализа зависимостей, такие как OWASP Dependency-Check, Snyk, GitHub Dependabot, WhiteSource, Solar appScreener и другие, могут автоматически сканировать проект и выявлять известные уязвимости в используемых библиотеках. Эти инструменты помогают своевременно обнаружить проблемы с безопасностью, прежде чем они приведут к инцидентам.

Анализаторы состава ПО (SCA) позволяет проверять безопасность сторонних библиотек, используемых разработчиками в своем ПО. Основные задачи такого вида анализа: обнаружение и отслеживание всех сторонних компонентов в ПО, выявление известных уязвимостей и закладок в сторонних библиотеках и предотвращение угроз и снижение рисков ИБ из-за заимствования кода.

Проверка репутации библиотеки

Перед использованием стороннего компонента важно убедиться в его репутации. Библиотеки с большим количеством звезд на GitHub, активным сообществом и регулярными обновлениями чаще всего являются более безопасными. Также стоит проверять, насколько быстро разработчики реагируют на отчетные уязвимости.

Автоматизированные инструменты для анализа цепочек поставок (SCS) решают задачи мониторинга подозрительной активности в используемых библиотеках и защиты от атак Supply Chain. Модуль Open Source Analysis (OSA) в составе Solar appScreener обеспечивает комплексный анализ для защиты от угроз, связанных с open-source-компонентами, который включает SCA и SCS.

Регулярные обновления сторонних библиотек

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

Аудит кода и тестирование

Помимо анализа библиотек на предмет уязвимостей, важно проводить регулярные аудиты кода. Инструменты статического анализа кода, такие как Solar appScreener, могут выявить потенциально опасные места в коде, где можно внедрить сторонние уязвимости.

Контроль версий и зависимостей

Важно ограничивать количество и версии используемых сторонних библиотек. Наилучшей практикой является создание контрольных списков зависимостей и настройка CI/CD-пайплайнов таким образом, чтобы зависимости автоматически проверялись на соответствие безопасности.

Итого

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