В начале 2024 года эксперты из компании Oversecured выпустили отчет о новом типе атак MavenGate на цепочку поставок для Java и Android-приложений. Выяснилось, что ей подвержены более 18% всех Java-библиотек с открытым исходным кодом. Такая уязвимость дает возможность злоумышленникам внедрить вредоносный код в приложение, атакуя его зависимости. В этом материале мы раскроем суть и методы реализации MavenGate и расскажем, как защитить от нее свой проект.
В чем суть
Все проекты системы Gradle имеют репозитории, которые помогают сборщику найти зависимости. Самые популярные – MavenCentral, JCentral и JitPack с Google (для Android).
Список зависимостей, которые ищет сборщик, обычно представлен в формате groupId:artifactId:version, например com.google.code.gson:gson:2.10.1
Чтобы опубликовать библиотеку, необходимо владеть доменом, который относится к ее group.id. Например, выложить пакет с именем ru.stingraymobile может только владелец домена stingraymobile.ru. Подтвердить личность нужно через TXT-запись.
Допустим, вы опубликовали свою библиотеку в репозиторий JitPack, но через какое-то время не продлили регистрацию домена или вовсе про него забыли. Тогда злоумышленник сможет его купить и подменить библиотеку в процессе сборки приложения. В случае с GitHub-аккаунтами сделать очень просто, так как зачастую репозитории позволяют использовать их в качестве подтверждения авторства без необходимости приобретать домен.
Масштаб проблемы больше, чем может показаться
Эксперты Oversecured проанализировали 33 938 доменов (all.txt) и выяснили, что 6170 или 18,18% (vulnerable.txt) из них оказались уязвимыми. Это касается только MavenCentral, но если вспомнить, что эти библиотеки входят в множество других репозиториев, то можно предположить более печальную статистику.
Авторы исследования уже направили информацию об уязвимостях в более чем 200 компаний, в числе которых Google, Facebook, Amazon, Microsoft и другие крупные корпорации. Под ударом находятся все проекты, которые используют небезопасные библиотеки, поскольку:
- Злоумышленники могут свободно зарегистрировать домен или использовать имя автора на GitHub;
- Это можно сделать, обладая лишь базовыми знаниями по созданию скриптов;
- Транзитивные зависимости тоже уязвимы, а вместе с ними и множество проектов.
Как работают сборщики проектов
Специалисты «Стингрей Технолоджиз» проверили, как ведут себя инструменты сборки в конкретных ситуациях и дают ли они сигнал по обновлению в IDE (интегрированная среда разработки) в зависимости от расположения репозиториев.
Наша команда проверила две гипотезы:
- Версия библиотеки в разных репозиториях одинаковая. При указании конкретной версии, которая есть в обоих репозиториях, библиотека загрузится из первого обнаруженного. Например, если первым в файле сборки указан JitPack, то загрузка будет из него. Это значит, что соблюдать порядок очереди при указании репозиториев нужно и важно. Практика показывает, что многие разработчики этим пренебрегают.
- Версия библиотеки разная в двух репозиториях (в файле сборки это не указано). Здесь уже сложно отследить, что будет происходить с зависимостями, так как неизвестно, какая версия выставлена и откуда она будет загружаться. Мы провели анализ поведения систем сборки и выяснили, что при объявлении версии библиотеки, как самой свежей (сделали через команду :+), загружается самая последняя версия, которая была найдена во всех указанных в файле сборки репозиториях. А это значит, что и злоумышленник способен опубликовать обновленный вариант, который сборщик скачает как самый новый.
Можем сделать вывод, насколько важно правильно указывать порядок репозиториев и сами версии, с которыми работает программа, чтобы избежать неожиданностей и нападений киберпреступников.
Как проводится атака
Рассмотрим реализацию атаки на примере библиотеки org.xmlmatchers (присутствует только в репозитории MavenCentral):
- Злоумышленник покупает свободный домен xmlmatchers.org за 10$;
- Затем регистрируется во всех публичных репозиториях с первичной валидацией по домену и загружает в них библиотеку, содержащую полезную нагрузку в дополнение к основному функционалу с той же версией, что и в MavenCentral и на одну минорную версию выше;
- Далее система сборки (в зависимости от расположения репозиториев), может загрузить вредоносный пакет вместо легитимного. В дополнение к этому, IDE подсветит возможное обновление библиотеки;
- Таким образом, все проекты, использующие эту зависимость (и у кого установлен первым не MavenCentral-репозиторий), получат версию злоумышленника.
С другой стороны, есть и обратная ситуация, в которой библиотека есть, например в JCentral, но ее не загрузили в MavenCentral. В таком случае, действия злоумышленника аналогичны описанным выше шагам, за исключением того, что теперь атаке подвержены все проекты, у которых стоит первым репозиторием MavenCentral.
Можем сделать вывод, что данную атаку произвести довольно просто. Из плюсов – вряд ли она будет целенаправленной, так как злоумышленник не сможет предсказать, в какой из проектов попадет его библиотека.
Неизвестно, кто именно и для чего приобретает свободные домены. Например, ini4j.org куплен 23 января, а домен jdesktop.org зарегистрирован 19 января. Это вполне могут быть действия злоумышленников, которые нацелены на реализацию атаки.
Как защитить свои проекты
Защитить приложения от MavenGate можно несколькими способами. Надежнее будет воспользоваться сразу всеми рекомендациями:
- Проведите анализ всех библиотек проекта. Изучите все прямые и транзитивные зависимости. Найдите библиотеки со старыми или доступными для продажи доменами и исключите эти зависимости из проекта. Также проверьте, чтобы в файлах сборки не было версий пакетов, ссылающихся на самый новый вариант без прямого указания.
- Проверьте хэш файлов проекта. Важно убедиться, что в них нет скомпрометированных библиотек. Также нужно следить за файлом во время обновления.
- Проверьте подписи загружаемых библиотек. Открытые ключи публикуются редко, но это по-прежнему рабочий способ защиты от данной атаки.
Организации, использующие внутренние репозитории в зеркальном режиме (когда библиотека сначала загружается во внутренний репозиторий и при последующих обращениях делится сохраненным файлом), не так подвержены MavenGate, как библиотеки из публичных репозиториев. Но на практике мы сталкиваемся с самыми разными сценариями атак, поэтому рекомендуем проверять все библиотеки на предмет возможности захвата домена. Особенно те, что попали в проксирующий репозиторий после публикации статьи.
Вывод
Атака MavenGate проста только на первый взгляд. Уязвимая библиотека может находиться в любом проекте и по цепочке подвергать опасности все связанные с ней приложения. В худшем случае жертвами могут стать множество компаний и их пользователей.
Важно предпринять меры по обнаружению подобных зависимостей в ваших проектах уже сейчас, чтобы проблема точно обошла вас стороной. Команда «Стингрей Технолоджиз» проверяет SBOM-файлы мобильных приложений Android на подверженность атаке MavenGate и помогает клиентам защитить свои продукты от этой проблемы, а также многих уязвимостей. Чтобы обезопасить свое приложение, смело пишите нам.
Подписывайтесь на Telegram-канал Mobile AppSec World, чтобы быть в курсе всех событий из мира безопасности мобильных приложений.
Реклама. ООО «СТИНГРЕЙ ТЕХНОЛОДЖИЗ» ИНН 9731060805