Совместные Open Source-проекты насчитывают миллионы строк кода, отдельные части которого переплетаются с кодом других открытых проектов. Древовидная структура зависимостей кода может поставить под угрозу небольшие открытые проекты, если их сумеют заразить вредоносным кодом киберпреступники, пишет портал DARKReading.

В последние годы популярность Open Source достигла той стадии, когда подавляющее большинство организаций начало включать его в свою критически важную инфраструктуру. Тем не менее, следует знать, что открытый код может представлять легкую добычу для злонамеренных действий со стороны разработчиков, принимающих участие в его создании. Основатель Zero Day Consulting Брэд Коузи считает, что вездесущность кода, которая проистекает от самой природы проектов с открытым исходным кодом, представляет реальную угрозу для предприятий. Подключившись к целевому Open Source-проекту, перед преступником открывается широкий выбор возможностей, правда, в рамках узкого коридора: «Чтобы раздобыть ценную информацию, но при этом не раскрыть себя, хакерам нужно действовать быстро. Для осуществления этой цели они могут прибегнуть к встроенному кейлоггеру или какому-то другому трояну».

Открытость, свободный доступ к коду, прозрачные политики управления — все это делает Open Source желанной добычей для хакеров. «Это довольно известный вектор атаки. Предполагаю, что мы осведомлены о сравнительно небольшом количестве атак, на самом деле их проводится гораздо больше», — считает директор по исследованиям Veracode Крис Энг.

К этим мнениям присоединяется голос еще одного эксперта. «Это происходит вокруг нас. В истории ИБ бывали случаи, когда хакеры атаковали открытый код и нет никаких оснований полагать, что они на этом остановились», — полагает руководитель департамента по исследованию проблем безопасности Checkmarx Эран Ялон. Прежде, чем код будет принят в тот или иной Open Source-проект проект, практически все его участники должны пройти проверку, которая проводится другими участниками, напоминает он. Тщательность проверки зависит от репутации человека — чем большим доверием к нему проникаются, тем меньше потребность в его проверке или она становится символической.

Однако в основном проверку участников проводят известные проекты, такие, к примеру, как сообщества крупных дистрибутивов Linux. У них процедуры проверки четко налажены, поскольку в крупных проектах задействовано большое количество участников, что позволяет проводить их на постоянной основе. «Небольшие проекты лишены таких ресурсов, поэтому не могут обеспечить сравнимый с крупными проектами уровень безопасности. Таким образом, эти проекты становятся все более уязвимыми», — говорит Коузи.

Маленький проект, большое влияние

В качестве основной цели для злоумышленников эксперты называют небольшие проекты Open Source. Способ проникновения в них — инфицирование при помощи вредоносного кода. «Большой пакет может состоять в зависимости даже с самым крохотным пакетом. В некоторых случаях количество уровней, на которые могут уходить зависимости, не поддается исчислению. Когда вы приступаете к созданию проекта и вам кажется, что у него будет лишь одна или две зависимости, на самом деле их может быть несколько сотен. Проверить их все — нереально», — говорит Ялон. Осенью прошлого года стало известно, что в Open Source-проект Event-stream, который поддерживался одним разработчиком, был встроен вредоносный код. Его внедрили в библиотеку кода, распространяемую через NPM — популярный менеджер пакетов для разработчиков Javascript.

«Event-stream — это небольшой проект, который зависел от доброй воли одного участника, у которого к тому же не было достаточно времени для его поддержки, — объясняет Ялон. — В итоге хакеру удалось убедить его в том, что он может взять управление проектом на себя». Далее, чтобы не вызывать подозрений, хакер решил пойти по проторенной тропе, какое-то время поддерживая код проекта в рабочем состоянии, однако после он посчитал, что пора перейти ко второй фазе атаки. Ею собственно стала модификация кода в пакете с зависимостями — в него был вставлен код, который предназначался для взлома некоторых биткоин-кошельков. О масштабах атаки красноречиво говорят цифры. В среднем код Event-stream за неделю скачивается почти 1,5 млн. раз, он задействуется в более чем 1600 других пакетах, счет загрузок которых идет на миллионы.

Следующий пример показывает, к каким последствиям могут привести проблемы с компоновкой одного небольшого пакета, которые даже не связаны с злонамеренными действиями. 23 марта 2016 г. разработчик Азер Кочулу удалил 250 написанных им модулей, которые распространялись по каналу NPM. Один из этих модулей (left-pad) был очень маленьким фрагментом кода — он состоял из 11 строк и добавлял пробелы в левой части строк текста, чтобы он вписывался в определение переменной. В тот же день разработчики со всего мира заметили, что с их программами на JavaScript что-то не так. Одно из предупреждений гласило: «npm ERR! 404 ’left-pad’ is not in the npm registry». Это означает, что для запуска проекта требуется пакет под названием left-pad, но получить его не удается. Многие разработчики не могли понять, что случилось: они никогда не использовали такой модуль. Однако его могли использовать другие модули, о чем можно было просто не догадываться.

Как позже выяснилось, left-pad применяется в тысячах корпоративных и коммерческих программ по всему миру, в том числе созданных с помощью компилятора Babel для Javascript и программной платформы Node. После того, как код left-pad исчез из репозиториев, тысячи программ перестали работать. На первый взгляд кажущаяся пустяковой проблема (разработчики могли легко воссоздать функциональность left-pad в своих пакетах) оказала огромное влияние на мир разработки.

Универсальная угроза

«Считаю нужным подчеркнуть, насколько распространен открытый код. По данным Gartner, его применяют для своих внутренних проектов 95% предприятий», — говорит Энг. Учитывая, что современная разработка все больше тяготеет к методикам ускоренного программирования типа Agile и DevOps, считает он, для обеспечения наилучшей защиты предприятиям нужно идти одним единственно верным путем — создания внутренней команды разработчиков, которые пишут для проекта свои собственные функции и библиотеки.

Так каким же образом эта внутренняя команда разработчиков может повысить безопасность кода? «На первом этапе нужно определиться с выбором библиотек и проектов с открытым кодом, которые дополнят технологический стек предприятия. Отталкиваться следует от надежности и репутации проектов», — говорит Коузи. На втором этапе следует убедиться, насколько этот проект активен и снабжается ли он регулярными обновлениями. «Активность почти всегда означает качество. Чем больше в проекте задействовано активных людей, тем больше вероятность того, что они устранят уязвимости», — объясняет он.

Третий этап — установка патчей безопасности. По словам Энга, в настоящее время многие организации беспокоятся по поводу так называемых уязвимостей нулевого дня, выражая свое недовольство, что государственные субъекты не в состоянии провести «базовую гигиену кода». «У этой проблемы есть одно базовое решение — обновление и базовое сканирование открытого кода», — сказал он.

В свою очередь Ялон считает, что наилучшая гарантия безопасности — доверие к Open Source-проекту и внутреннему разработчику, который его применяет. «Вредоносные пакеты с открытым кодом — это не повод для беспокойства, если их никто не использует, — говорит он. — Задействуя ПО с открытым кодом, каждая организации должна установить четкие правила для тех, кто может обновлять или изменять программные пакеты».