Захват чужих snap‑пакетов через просроченные домены: новый класс угроз
В экосистеме Snap обнаружился тревожный вектор атак: злоумышленники перестали ограничиваться созданием поддельных учётных записей и переключились на перехват уже существующих аккаунтов разработчиков через просроченные домены, привязанные к их почтовым адресам. На проблему обратил внимание Алан Поуп, ранее отвечавший за инженерное направление и взаимодействие с разработчиками в Canonical.
Как работает атака через просроченный домен
Схема относительно проста, но крайне эффективна:
1. Злоумышленник отслеживает домены, указанные в email‑адресах владельцев популярный или доверенных snap‑пакетов.
2. Когда срок делегирования домена истекает, и владелец его не продлевает, домен становится свободным для регистрации.
3. Нападающий выкупает освободившийся домен и настраивает почтовые записи так, чтобы получать всю корреспонденцию, идущую на старые адреса разработчика (например, dev@company‑name.tech).
4. Далее инициируется восстановление пароля к учётной записи в Snap Store: система шлёт письмо на тот самый адрес, контроль над которым уже перехвачен.
5. Получив доступ к аккаунту разработчика, злоумышленник может выпускать обновления существующих пакетов — теперь уже с вредоносным кодом.
Важно, что такой захват позволяет обойти многие защитные механизмы. С точки зрения платформы это не новый, сомнительный аккаунт, а давно существующий, публикующий ранее безопасные версии приложения. Пользователь, привыкший доверять этому пакету, вряд ли заподозрит подмену.
Конкретные случаи, обнаруженные исследователями
Алан Поуп сообщил как минимум о двух доменах, которые, по его данным, были выкуплены с целью перехвата аккаунтов разработчиков snap‑пакетов:
- enstorewise.tech
- vagueentertainment.com
С высокой вероятностью эти случаи — лишь вершина айсберга: отследить все просроченные домены, когда‑то использовавшиеся для регистрации разработчиков, сложно, а системная проверка в Snap Store долгое время просто не выполнялась.
Как злоумышленники действовали раньше
До появления этого вектора атаки основным способом компрометации пользователей Snap Store были:
- Публикация вредоносных пакетов под видом официальных: создавались учётные записи, визуально или по имени напоминающие оригинального разработчика, а пакет маскировался под известное приложение.
- Тайпсквоттинг: регистрация пакетов с именами, похожими на популярные (опечатка в одну букву, лишний символ и т.п.), чтобы перехватывать невнимательных пользователей.
В ответ Canonical усилила модерацию: новые имена пакетов стали проходить ручную проверку, что заметно усложнило жизнь тем, кто пытался паразитировать на известных брендах и названиях.
После ужесточения правил нарушители сместили акцент:
- стали чаще публиковать оригинальные «честные» пакеты, которым сначала создавали репутацию;
- активно рекламировали их в соцсетях;
- а уже спустя время выкладывали обновление с вредоносной функциональностью, надеясь, что автоматические проверки не поймают подмену сразу.
Почему просроченный домен — такая опасная дыра
Новый подход с выкупом доменов оказался ещё изощрённее. Его главная сила — в комбинации трёх факторов:
1. Неочевидность риска для разработчика. Многие регистрировали домен «под проект» или под компанию, которая со временем закрылась, а затем перестали его продлевать, забыв, что именно на этот домен завязана критичная учётная запись.
2. Отсутствие проверки актуальности домена на стороне Snap Store. Платформа длительное время не отслеживала, истёк ли домен, привязанный к email разработчика.
3. Высокий уровень доверия к уже существующим пакетам. Когда от имени старого, знакомого приложения выходит обновление, подавляющее большинство пользователей устанавливают его без сомнений.
В результате атака оказывается тихой и крайне опасной: злоумышленник получает возможность внедрить вредоносный код в ПО, уже установленное на множестве систем.
Опыт PyPI: как другие решали аналогичную проблему
С похожей уязвимостью ранее столкнулся репозиторий Python‑пакетов PyPI. Там также обнаружили, что часть аккаунтов разработчиков привязана к адресам с доменами, срок действия которых истёк. Такой сценарий даёт тем же злоумышленникам почти идентичный набор возможностей — перехват писем и сброс паролей.
Реакция была жёсткой и быстрой:
- система начала автоматически переводить email‑адреса с просроченными доменами в статус неподтверждённых;
- владельцам таких аккаунтов требовалось подтвердить новые актуальные адреса.
В результате было заблокировано свыше 1800 почтовых адресов с неактуальными доменами, что существенно сократило потенциальное поле для атак.
Почему одной проверки email‑адреса недостаточно
Простая проверка на синтаксис email или однократное подтверждение при регистрации сегодня уже не спасает. Ситуация кардинально изменилась:
- домен может быть валидным в момент регистрации, но стать доступным для выкупа спустя год или два;
- сам факт использования кастомного домена повышает риск — у владельца может банально закончиться бюджет на его продление, измениться юридическое лицо или стратегия, администратор уйдёт из компании и не продлит домен вовремя.
Для платформ распространения ПО этого достаточно, чтобы потенциально «открыть дверь» в доверенный аккаунт через стандартную процедуру восстановления пароля.
Что должны делать платформы вроде Snap Store
Чтобы закрыть этот класс уязвимостей, владельцам репозиториев имеет смысл:
1. Регулярно проверять состояние доменов, привязанных к email‑адресам разработчиков.
2. Автоматически помечать аккаунты с просроченными доменами как требующие вмешательства: блокировать публикацию новых версий до подтверждения актуального адреса.
3. Вводить дополнительные факторы аутентификации:
- обязателен либо сильно рекомендован двухфакторный вход;
- отдельные действия (смена email, сброс пароля, публикация особо популярных пакетов) могут требовать дополнительного подтверждения.
4. Уведомлять разработчика заранее, если домен, на который завязан его email, находится на грани истечения, основываясь на публичных данных о регистрации домена.
5. Проводить выборочные ручные проверки обновлений для наиболее популярных и критичных пакетов, даже если они исходят от старых, «надёжных» аккаунтов.
Как разработчикам обезопасить свои учётные записи
Ответственность лежит не только на платформах. Разработчикам стоит выстроить гигиену работы с доменами и почтой:
- Продумывать «жизненный цикл» домена. Если email на своём домене используется для регистрации в критичных сервисах (репозиторий пакетов, платёжные системы, хостинг кода), домен нельзя бросать, даже если проект свернулся.
- Разделять зоны ответственности. Для учётных записей, через которые распространяется ПО конечным пользователям, разумно использовать либо:
- домены, продление которых обеспечено долгосрочно;
- либо крупные почтовые сервисы с высокой стабильностью, если нет уверенности, что собственный домен будет поддерживаться годами.
- Обязательно включать двухфакторную аутентификацию, чтобы компрометация одного лишь почтового ящика не давала мгновенный доступ к аккаунту.
- Регулярно пересматривать контактные данные в репозиториях: менять администратора домена, перенастраивать email, фиксировать ответственных.
Риски для пользователей: почему важно обращать внимание на детали
Обычным пользователям Snap‑пакетов может казаться, что подобные истории касаются только разработчиков, но это не так. Захват учётной записи автора — это прямой путь к:
- подмене бинарников на версии с встроенным майнером, бэкдором или шпионскими функциями;
- внедрению вредоносного кода в приложения, которые пользователи считают «еталонными» и безопасными;
- атакам на бизнес‑среды, где такие пакеты развернуты массово.
Пока механизмы защиты не станут по‑настоящему зрелыми, пользователям стоит:
- внимательно смотреть на запрашиваемые приложением разрешения после обновления;
- обращать внимание на резкие изменения в поведении давно установленного ПО;
- по возможности использовать дополнительные уровни изоляции и мониторинга.
Будущее безопасной дистрибуции приложений
Случай со Snap Store демонстрирует общий тренд: по мере того как автоматические проверки и модерация улучшаются, злоумышленники уходят глубже — к социальным и инфраструктурным атакам, используя человеческую небрежность, забытые домены и старые контакты.
Репозитории приложений вынуждены эволюционировать от простых механизмов публикации к полноценным системам управления доверием:
- проверка цепочек владения доменами;
- привязка аккаунтов к более устойчивым идентификаторам;
- многоуровневая аутентификация и продуманная политика восстановления доступа;
- анализ аномального поведения аккаунтов, внезапно меняющих характер обновлений.
История с просроченными доменами вокруг Snap — это не «частный казус», а яркий пример того, как недоработка в, казалось бы, второстепенной детали (актуальность почтового домена) может привести к системным рискам для всей экосистемы. Чем раньше такие «тонкие места» будут признаны критичными и закрыты, тем меньше шансов, что доверенные приложения превратятся в удобный транспорт для вредоносного кода.
