Опасные связи: как преступники взламывают ИТ-продукты через GitHub

[BOOX]

В новой статье читайте советы экспертов по защите от кибератак через сторонние репозитории кода.


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

Это далеко не первая подобная история. В сентябре

Для просмотра ссылки необходимо нажать Вход или Регистрация

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

Для просмотра ссылки необходимо нажать Вход или Регистрация

,

Для просмотра ссылки необходимо нажать Вход или Регистрация

в систему и т.д. Специалисты

Для просмотра ссылки необходимо нажать Вход или Регистрация

в том, что атаки через GitHub будут только расти.

Мы обсудили с экспертами самые частые сценарии атак на репозитории кода и способы защиты от таких угроз. Выяснилось, что разные специалисты смотрят на эту тему по-разному, что еще раз доказывает: безопасность кодовой базы — комплексная проблема, и единого, всем подходящего решения для нее пока нет.

Какие атаки проводятся через инфраструктуру GitHub​

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

Если перечислить все уязвимости, то это займет очень много времени, поскольку любая уязвимость, начиная от XSS (cross site scripting) и заканчивая RCE (remote code execution) может нанести серьезный урон. Банальное перекрашивание логотипа в цвета украинского флага в наши дни может принести больше негатива, чем кража конфиденциальной информации.

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

В то же время, примеры атак, которые встречаются в реальной практике, довольно ограничены с точки зрения технологий. Как правило, речь идет о перехвате контроля над репозиторием (repojacking), внедрении вредоносных закладок и бэкдоров в легитимное ПО, подмене библиотек и open-source-компонентов, используемых в продукте.

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

Перехват контроля над репозиторием ПО (repojacking)​

Нетрудно оценить последствия, если злоумышленник сможет взломать учетную запись владельца репозитория. Фактически речь о полном потере контроля над ИТ-продуктом.

Самый распространенный пример такого сценария — уязвимости перенаправления для переименованных GitHub-репозиториев. Когда владелец репозитория меняет имя репозитория или имя пользователя, сервис создает новый URL для его хранилища. Обычно GitHub автоматически перенаправляет ссылки на новый URL-адрес, чтобы ПО, использующее переименованный проект, продолжало функционировать.

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

Крайне редкая атака, среди наших клиентов не встречалась. В последние 2 года большинство наших заказчиков перестало пользоваться именно репозиториями, чаще делают копию и сопровождают ее самостоятельно — по сути, создают клон (fork) репозитория из github. Тут есть как плюсы (почти нет шансов встроиться с malware и прочим), так и минусы (багфикс или развитие компоненты надо вести самостоятельно).

Относительно новая тема, присущая площадке GitHub. Для ее эксплуатации нужны особые условия, которые не всегда осуществимы. Например, разработчик, чей код вы используете, должен сменить свое имя, у него должно быть меньше 100 лайков и так далее.
Но в целом момент достаточно коварный и защититься от этой уязвимости достаточно сложно. Компаниям нужно быть внимательными, если они не хотят потерять контроль над репозиторием после проведения ребрендинга на GitHub. Должны быть описаны процессы разработки с использованием площадки, процессы создания нового репозитория, жизненный цикл старого, ответственные лица.

Опасная штука, особенно если перехват неявный. Мало того, что у злоумышленников появляется доступ к приватным (конфиденциальным) проектам, так еще и возрастает риск внедрения паразитных компонентов.

Внедрение вредоносного кода​

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

Это самая распространенная атака. По сути, ради внедрения закладок все и затевается. Провести атаку в лоб на системы больших компаний сейчас уже нереально, поэтому злоумышленники ищут слабые места, которые находят в компонентах с открытым кодом.

Здесь наиболее вероятным и популярным сценарием я бы назвал атаки на цепочку поставок (supply chain attack) — когда злоумышленник внедряет вредоносный код в компоненты ПО. Достаточно масштабная кибератака — это

Для просмотра ссылки необходимо нажать Вход или Регистрация

Для просмотра ссылки необходимо нажать Вход или Регистрация

. Преступники получили доступ ко всем пользователям — крупным компаниям США, в том числе государственным организациям.

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

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

Подмена библиотек и open-source-компонентов​

О рисках открытого кода специалисты говорят уже очень давно. Еще в 2018 году

Для просмотра ссылки необходимо нажать Вход или Регистрация

, что компании продолжают все больше применять open-source-модули с известными уязвимостями. При этом эксплойты к таким компонентам появляются буквально в течение дней после появления PoC.

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

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

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

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

Ухудшение работы ИТ-продуктов из-за доступных публично некачественных компонентов​

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

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

Можно отметить возможные проблемы с лицензированием при доработке ПО, отсутствие обязательств разработчика по поддержке ПО.

Мы бы рекомендовали оценить, насколько действительно необходимо использование open source-решений в ИТ-инфраструктуре. При наличии аналогичных коммерческих продуктов российских разработчиков — применять отечественные решения, в ином случае рекомендуем разрабатывать и регулярно актуализировать перечень компенсирующих мер, использовать аудит и выстроить процесс управления инцидентами ИБ.

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

Как защититься от атак на репозитории кода​

Примечательно, что главной причиной проблем с процессами разработки собеседники Cyber Media часто называют собственно некачественные процессы. Проверки кода вручную и автоматически, внедрение подходов DevSecOps, ответственное отношение к релизам продуктов — по словам специалистов, эти меры снимают значительную часть рисков.

В 2022 году таких репозиториев стало гораздо больше, и «под раздачу» тогда мог попасть абсолютно любой.

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

Если вы коммерческая компания, рекомендуется при выборе ПО убеждаться в том, что он проверен на соответствие требованиям безопасности. Если это невозможно подтвердить, то проводить приемочные испытания в изолированном контуре с учетом всевозможных рисков ИБ.

Следует нанять опытного разработчика, а лучше нескольких, и проводить периодические тестирования с командой DevSecOps, например тестирование «белого ящика» (Static Application Security Testing), и «черного ящика» (Dynamic Application Security Testing).

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

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

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

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

Для просмотра ссылки необходимо нажать Вход или Регистрация