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

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

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

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

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

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

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

Антон Башарин

Технический директор Swordfish Security

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

Фуркат Рахмонов

Инженер по информационной безопасности iTPROTECT

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

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

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

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

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

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

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

Антон Башарин

Технический директор Swordfish Security

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

Андрей Жуков

Ведущий специалист по анализу защищенности УЦСБ

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

Григорий Кононенко

Руководитель технического направления ARinteg

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

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

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

Антон Башарин

Технический директор Swordfish Security

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

Андрей Жуков

Ведущий специалист по анализу защищенности УЦСБ

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

Григорий Кононенко

Руководитель технического направления ARinteg

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

Фуркат Рахмонов

Инженер по информационной безопасности iTPROTECT

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

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

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

Андрей Жуков

Ведущий специалист по анализу защищенности УЦСБ

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

Григорий Кононенко

Руководитель технического направления ARinteg

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

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

Антон Башарин

Технический директор Swordfish Security

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

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

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

Антон Башарин

Технический директор Swordfish Security

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

Андрей Жуков

Ведущий специалист по анализу защищенности УЦСБ

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

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

Григорий Кононенко

Руководитель технического направления ARinteg

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

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

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

Андрей Жуков

Ведущий специалист по анализу защищенности УЦСБ

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

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

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

Фуркат Рахмонов

Инженер по информационной безопасности iTPROTECT

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

Андрей Ефимов

Инженер департамента информационной безопасности ИМБА ИТ

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

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

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

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