Уязвимость GitHub позволяла угнать чужой репозиторий в обход защиты

Уязвимость GitHub позволяла угнать чужой репозиторий в обход защиты

Уязвимость GitHub позволяла угнать чужой репозиторий в обход защиты

Команда Checkmarx обнаружила брешь в защите облачного хостинга GitHub от клонирования репозиториев в рамках атак на цепочку поставок. Как оказалось, создать такой источник вредоносного кода все еще можно, притом легко — путем переименования.

Хранилища на GitHub получают уникальные URL, которые привязываются к аккаунту владельца. Когда пользователь меняет имя аккаунта, на веб-сервисе создаются редиректоры. В Checkmarx придумали, как угнать перенаправленный трафик, сломав логику редиректа, и назвали свой способ RepoJacking.

В итоге на GitHub появился дополнительный механизм защиты, отвечающий за удаление популярных, но устаревших пространств имен (связок имя пользователя / имя репозитория) — чтобы ими не воспользовались злоумышленники. Эта контрмера пускается в ход, когда недельная норма клонов opensource-проекта перевалит за сотню.

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

  • злоумышленник создает репозиторий с именем (условно repo), выведенным из обихода, но под другим аккаунтом, разрывая связку (например, вместо прежнего юзернейма victim использует helper);
  • helper_account передает репозиторий repo новому владельцу (attacker) в соответствии с принятым регламентом;
  • тот переименовывает свой аккаунт в victim;
  • новоявленный victim_account принимает запрос на передачу права собственности.

В итоге пространство имен victim/repo попадает под контроль авторов атаки — из-за того, что специализированная защита GitHub считает устаревшей только комбинацию юзернейм / имя репозитория. По словам Checkmarx, подобным образом можно угнать любой популярный софт, если его владелец менял имя пользователя.

Просмотр каталогов Go, Swift и Packagist выявил более 10 тыс. пакетов, находящихся в зоне риска. Оператор GitHub устранил опасную уязвимость в прошлом месяце — 19 сентября.

Подпишитесь на новости

Минцифры увидело риск блокировки российских приложений на Android

Новый механизм проверки разработчиков Android может осложнить установку российских приложений, особенно уже удалённых из официальных магазинов. Минцифры оценивает угрозу и вместе с отраслью готовит варианты, как не позволить Google превратить установку APK в квест с непредсказуемым финалом.

Об этом заявил глава ведомства Максут Шадаев. По его словам, сейчас приложения на Android можно свободно устанавливать из сторонних источников, но изменение правил верификации способно ограничить такую возможность.

«Мы смотрим на это как на риск того, что, условно, завтра нельзя будет поставить приложения», — сказал Шадаев на конференции «День ТризТех». Министр уточнил, что речь идёт о сценарном анализе, а не об уже объявленном Google запрете.

Google вводит обязательную регистрацию разработчиков и приложений, распространяемых не только через Google Play, но и за его пределами. Новые правила должны заработать 30 сентября 2026 года в Бразилии, Индонезии, Сингапуре и Таиланде, а с 2027 года компания планирует расширить их на сертифицированные Android-устройства по всему миру.

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

Интересно также, что команда LineageOS решила успокоить своих пользователей: на устройства с этой кастомной прошивкой новая система проверки разработчиков не повлияет.

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

Напомним, на «День ТризТех» Шадаев призвал вендоров NGFW искать деньги у заказчиков, а не у государства.

RSS: Новости на портале Anti-Malware.ru