Безопасны ли открытые двери

В декабре 2021 года в популярной Java-библиотеке с открытым кодом Log4J обнаружили уязвимость «нулевого дня». Ошибка получила название Log4Shell. Компании и государственные организации принялись устранять брешь в безопасности, однако эксперты утверждают, что она будет представлять угрозу по крайней мере вплоть до 2032 года. Сегодня, по данным компании Synopsys, 96 процентов коммерческих программ содержат открытый исходный код. И хотя исследования показывают, что лидеры IT-рынка в большинстве доверяют выбору корпоративных опенсорс-продуктов, инцидент с Log4Shell — это повод задуматься, насколько на самом деле безопасен открытый код.

Как оценить безопасность софта?

В 2022 году платформа для дата-сайентистов Anaconda опросила более 3 тысяч профессионалов из числа своих пользователей, посвятив несколько вопросов опенсорсу. Среди опрошенных 40 процентов рассказали, что в 2021 году их компании начали отказываться от софта с открытым кодом из-за опасений по поводу его безопасности, а 31 процент специалистов заявили, что на сегодняшний день уязвимости — главная проблема опенсорса. Однако сама по себе модель разработки не определяет уровень защищенности софта.

«Опасность» открытого кода обосновывается тем, что кто угодно может встроить зловредный код, особенно если состоит в сговоре с людьми, которые утверждают изменения. Но фактически на безопасность опенсорса влияет то же самое, что и на проприетарный код, — наличие того, кто отвечает за безопасность и занимается ею, не полагаясь на сообщество.

Чтобы считаться надежным, ПО должно соответствовать регламентам и стандартам, таким как , или . Безопасность складывается из множества факторов:

1. Принципы разработки. Следование политикам и стандартам безопасности: использование криптографии, обработка ошибок, аутентификация пользователей и так далее.
   
2. Аудит безопасности. Регулярная и систематическая проверка исходного программного кода для выявления уязвимостей и ошибок.
   
3. Тестирование и отладка. Валидация кода на наличие ошибок и уязвимостей. Она позволяет выявлять и устранять проблемы, которые злоумышленники могут использовать в качестве точек входа.
   
4. Внедрение принципа минимальных привилегий. Принцип ограничения доступа и разграничения прав пользователей помогает предотвратить распространение уязвимостей и потенциальных атак внутри системы.
   
5. Обучение разработчиков практикам безопасности.

Для продвижения этих принципов и повышения безопасности ПО с открытым исходным кодом разработчики и компании по всему миру объединились в фонд, поддерживающий безопасную разработку опенсорса, — Open Source Security Foundation (OpenSSF). Он создан для обмена информацией и призван решить вопросы с безопасностью, в том числе даже в автоматическом виде. OpenSSF стремится предоставить разработчикам возможность изучать методы безопасной разработки и автоматически получать рекомендации по ним через приложения, которые они используют. Исследователи, выявляющие проблемы безопасности, отправляют информацию тем, кто может решить проблему. Кроме того, члены сообщества регулярно предоставляют информацию о компонентах, которые они используют и тестируют.

На практике защищенность софта во многом зависит от взаимодействия между отделами информационной безопасности (ИБ) и разработки. Специалисты по безопасности не должны вмешиваться в процесс на каждом шагу, и в то же время им необходимо контролировать соблюдение правил безопасности. При этом важно соблюсти баланс: если приоритет в коммуникации отдается ИБ, разработчики могут почувствовать излишние ограничения, затрудняющие работу; если наоборот — отдел безопасности может отстать от разработки, а софт будет соответствовать стандартам и регламентам, скорее всего, лишь формально.

Однако в общем случае ПО считают безопасным, если оно не содержит уязвимостей — ошибок, позволяющих, например, получить доступ к конфиденциальной информации пользователей. Но если уязвимость еще никто не нашел, это не означает, что ее нет. Даже в старом коде спустя время может быть найдена новая уязвимость. Известные уязвимости собирают в базах данных, которыми пользуются специалисты по информационной безопасности. Уязвимости ранжируются по уровню опасности, от незначительных к критическим. Зачастую незначительные уязвимости могут долго оставаться неисправленными, потому что разработчикам может быть полезнее потратить время и ресурсы на что-то другое.

Часто источником уязвимостей становится человеческий фактор: несоблюдение рекомендаций по безопасности, неправильная настройка программного обеспечения, простые пароли, отсутствие процессов проверки и методов шифрования данных. Например, в 2020 году администратор программы «РЖД Бонус» спровоцировал утечку, по ошибке поместив базу данных в корневой каталог сайта. Согласно исследованию компании Tessian и профессора Стэнфордского университета Джеффа Хэнкока, ошибками сотрудников вызваны 88 процентов утечек данных.

Закрытое ПО защищено лучше, чем открытое?

Существует заблуждение, что программы с закрытым исходным кодом лучше защищены от внешних угроз. Между тем, по данным американской технологической компании Qualys, которая также ссылается на отчет Агентства по кибербезопасности и защите инфраструктуры США (CISA), в 2022 году большая часть наиболее эксплуатируемых уязвимостей относилась именно к коммерческому ПО. От взлома не застрахованы даже самые крупные компании. Например, в декабре 2022 года хакеры взломали почтовый клиент Outlook и сервис OneDrive, принадлежащие Microsoft, и получили доступ к аккаунтам государственных служащих США.

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

Поскольку софт с открытым исходным кодом так или иначе используют многие компании, злоумышленники могут скомпрометировать отдельные части коммерческого ПО или сети его распространения. Например, захватить учетные записи участников проекта или воспользоваться уязвимостями в репозиториях.
Именно это произошло во время кибератаки на американскую компанию SolarWinds. Хакеры проникли в программное обеспечение для управления и мониторинга IT-инфраструктуры компании и модифицировали подключаемый модуль с открытым исходным кодом. Обновление программы Orion, которое затем скачивали пользователи, оказалось заражено вредоносным софтом Sunburst. Жертвами стали крупные технологические компании, такие как Microsoft и Cisco, но сильнее всего пострадали Казначейство, Министерство торговли и Министерство национальной безопасности США.

Согласно отчету компании Endor Labs, наибольший риск сегодня представляют известные, то есть наиболее распространенные и часто эксплуатируемые уязвимости. Разработчики стараются устранять их в первую очередь. Например, уязвимость CVE-2017-5638 в Apache Struts вызвала утечку данных бюро кредитных историй Equifax. Хакеры похитили данные 148 миллионов человек, включая имена, адреса, социальные страховые номера, даты рождения и номера водительских удостоверений. Расследование показало, что компания знала об уязвимостях в системе, но не устранила их вовремя. А уязвимость CVE-2021-44228, также известная как Log4Shell, в Apache Log4j до сих пор считается одной из самых опасных (в момент обнаружения ей был присвоен максимальный уровень опасности по шкале CVSS), поскольку эта библиотека используется во множестве Java-приложений. Поэтому, если не установить обновление вручную, у пользователя исправления не будет, даже если она сама по себе уже исправлена.

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

С какими рисками связано использование опенсорса?

По данным анализа, проведенного компанией Synopsys в 2023 году, 89 процентов кодовых баз содержат открытый исходный код, который устарел более чем на четыре года. Если компоненты проектов не обновляются в течение двух лет, скорее всего, это означает, что проект более не поддерживается. Иными словами, многие компании, использующие открытый код, — а такие есть повсюду, от авиации и энергетики до финтеха и здравоохранения, — уязвимы для кибератак.

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

Один из минусов опенсорс-разработки в том, что она может не учитывать современные инженерные практики обеспечения безопасности, такие как DevSecOps. Дополнительным риском становятся случаи, когда разработчики отказываются от поддержки пакетов, которые могут быть в составе ПО. Это создает не только потенциал для неисправленных уязвимостей, но и риск того, что в коде могут отсутствовать необходимые механизмы безопасности, такие как современное шифрование. Если разработчик перестал поддерживать какой-то пакет (компонент), то и шифрование со временем устаревает. Кроме того, бывают случаи, когда разработчики по тем или иным причинам сознательно портят код, находящийся в открытом доступе.

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

Есть ли у опенсорса преимущества?

Над проектом с открытым исходным кодом могут работать всего несколько постоянных участников, тогда как большинство разработчиков будут приходить и уходить. С одной стороны, это затрудняет работу над безопасностью, а с другой — новые люди могут посмотреть на код свежим взглядом и с большей вероятностью заметить ошибку. Поэтому замечать и исправлять уязвимости, позволяя быстро выявлять и устранять проблемы, потенциально могут тысячи людей. К сожалению, могут, но не всегда стремятся. По данным опроса Linux Foundation за 2020 год среди контрибьюторов по всему миру, только 3 процента из них тратят свое время на вопросы безопасности ПО. Впрочем, успешные проекты с открытым исходным кодом, как правило, обладают достаточным количеством ресурсов, чтобы привлекать сотрудников для аудита исходного кода. Например, в Mozilla для устранения проблем безопасности существует отдельная команда.

Однако, даже если злоумышленник попробует создать форк проекта, он не сможет манипулировать оригинальным репозиторием. Перед утверждением изменения пройдут через аудит специалистов. Это означает, что необходимо приложить дополнительные усилия, чтобы добавить в проект вредоносный код и воспользоваться уязвимостью. Подробнее о том, как устроена работа над опенсорс-проектам, читайте в материале «Софт для всех».

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

Несмотря на то что у коммерческого вендора выше мотивация вкладываться в безопасность, чем у энтузиастов, полностью полагаться на него нельзя. Поэтому, как и в случае опенсорса, пользователю также следует самому заботиться о безопасности. В конечном итоге недоверие к открытому ПО связано не с безопасностью, проблемы с которой существуют везде. Оно возникает, поскольку зачастую неясно, кого считать ответственным за безопасность. Если за надежность коммерческого софта несет ответственность компания-разработчик, то риски использования опенсорса ложатся на пользователя. Наталья Каперская, президент ГК Infowatch, считает, что нельзя строить системы государственной значимости исключительно на открытом коде. По ее словам, «open source — это „безответственное“ программное обеспечение, за которое никто не несет ответственности». Тем не менее множество компаний по всему миру поддерживают опенсорс и используют программы с открытым кодом. Подробнее о том, почему они это делают, читайте в материале «Философия кода».

Благодарим за помощь в подготовке материала Максима Лапшина, основателя и технического директора Flussonic.

Реклама: ООО «Веб-Сервер», ИНН 9704151517, Kra247g3A