Интегрированная среда разработки (IDE) Visual Studio Code от компании Microsoft используется 75% разработчиков, поэтому любая проблема безопасности имеет широкие последствия. И исследователи Aqua Nautilus обнаружили большую проблему.
Исследователи сообщили ранее в этом месяце, что редактор VSCode может быть уязвим для атак, направленных на его расширения. Бесплатная кроссплатформенная IDE с открытым исходным кодом очень проста в использовании, и существуют буквально тысячи бесплатных расширений, которые разработчики могут установить в один клик, чтобы ускорить свою работу.
Эти расширения обычно пишутся с помощью Node, а пакеты загружаются из NPM. что делает возможными обычные атаки по цепочке поставок на редактор кода. Кроме того, эти пакеты NPM имеют свои собственные зависимости, поэтому взлом может произойти практически из любой точки цепочки.
Для доказательства своей концепции исследователи использовали методы маскировки. Они выдавали себя за Prettier, чрезвычайно популярное расширение, используемое разработчиками для форматирования кода: «Чуть менее чем за 48 часов мы получили более тысячи установок от активных разработчиков со всего мира!»
Даже если не все пользователи попали в ловушку, тысячи установок более чем достаточно для нанесения серьезного ущерба, например, кражи учетных данных или утечки конфиденциальной информации.
Исследователи использовали классический типосквоттинг
Вместо «prettier-vscode» исследователи использовали «pretier-vscode», только с одной буквой «t», в URL расширения на рынке. Легко сделать опечатку, и только URL и несколько других деталей отличаются, поскольку исследователи смогли использовать тот же логотип, то же название, то же описание, даже точную копию оригинального readme.
Если пользователь набирает «pretier» в строке поиска, он даже не получит легитимное расширение в списке, поскольку только версия с опечаткой имеет такое название.
Этот подход активно используется субъектами угроз на других торговых площадках, таких как NPM и PyPI, но вредоносные расширения VSCode, похоже, находятся на подъеме, благодаря его доминирующему положению на рынке.
По мнению исследователей, опасность высока по двум основным причинам:
- любой может опубликовать расширение, которое может быть включено в список Marketplace
- все расширения запускаются с привилегиями пользователя, открывшего VSCode, без какой-либо песочницы
Идентификация вредоносных расширений
Определить вредоносные расширения нелегко. Посмотрите на скриншот ниже:
Вы заметите, что количество загрузок необычно мало для такого заметного расширения: 2k против 27M для настоящего. То же самое касается и количества оценок: 2 против 370.
Однако исследователи смогли воспроизвести почти все остальное, поскольку имена и названия не обязательно должны быть уникальными на платформе. Кроме того, количество загрузок или звезд можно было искусственно увеличить, чтобы добиться еще большего доверия.
Есть и другие различия, например, дата первого релиза (2022 против 2017), но если упустить эти детали, то легко попасть в ловушку, особенно если у вас нет времени на полную проверку источника.
Еще хуже то, что любой может получить галочку «Verified» рядом со своим именем, просто доказав право собственности на выбранное им доменное имя. По мнению исследователей, термин «Verified» может ввести в заблуждение многих пользователей.
Все реестры под угрозой
POC выглядит довольно убедительно, но эта проблема не относится только к рынку VSCode. Вся идея этих экосистем заключается в том, что любой может поделиться расширением, которое может стать очень популярным.
Даже если платформы проводят глубокое сканирование для обнаружения вирусов и других известных вредоносных программ, ничто не мешает расширению запросить URL-адреса из белого списка (или «не из черного списка»), например, кажущийся легитимным репозиторий GitHub, который содержит вредоносную полезную нагрузку. О таких фальшивых репозиториях в конечном итоге сообщают и уничтожают, но ущерб уже нанесен.
Исследователи также отметили, что легальные разработчики могут внедрять уязвимый код неосознанно. Иногда трудно отличить неудачный выбор кода от злого умысла.
Как противостоять угрозе VSCode
Следует отметить, что этот новый вектор атак еще не был замечен в природе, что может объяснить, почему о нем так мало информации.
Самая очевидная рекомендация для разработчиков – проявлять повышенную бдительность при установке любого расширения для своей любимой IDE. Используйте только проверенные источники, но помните о распространенных методах, используемых субъектами угроз, таких как typosquatting и masquerading.
Отговорка о нехватке времени в конечном итоге неприемлема. Как разработчик, вы несете ответственность, поэтому стоит потратить дополнительное время на тщательную проверку своих инструментов.
Однако, поскольку злоумышленники могут использовать и другие методы, такие как социальная инженерия, чтобы обманом заставить своих жертв загрузить вредоносные приложения, дополнительные меры могут помочь разработчикам смягчить эти угрозы:
- Вполне нормально тестировать новый инструмент в свободное время (например, в виртуальной машине), но не в рабочей среде.
- Просмотрите все запрашиваемые разрешения и возможности: Зачем программе нужен root-доступ? Оправдано ли это? Есть ли лучшие альтернативы?
- Если расширения должны «работать от вашего имени», перечислите свои собственные привилегии и, не колеблясь, удалите ненужные разрешения, если это возможно. Нужна ли вам постоянно учетная запись администратора?
- Отдайте предпочтение «песочнице» и другим механизмам изоляции: Активируйте их (они не обязательно включены по умолчанию) или установите специальный пакет, который будет ограничивать приложения и процессы.
- Защитите учетные записи с помощью MFA/2FA.
Очевидно, что принцип наименьших привилегий и контейнеры могут помочь значительно снизить угрозу. В этом конкретном случае пользователи могут также использовать «Worskspace trust» и «Restricted Mode».
В этом режиме расширения могут быть отключены автоматически или иметь ограниченную функциональность.
Однако это не волшебство, поскольку зависит от показаний автора, поэтому маловероятно, что субъекты угроз будут «оценивать свои расширения на предмет возможных уязвимостей безопасности и заявлять, что они имеют ограниченную поддержку при работе в режиме Restricted Mode», как того требует VSCode.
В качестве лучшего подхода я бы рекомендовал командам разработчиков следующее: Делиться и обсуждать новые инструменты или вести список общих расширений для установки для новых участников. Хорошей новостью является то, что это может быть заскриптовано и версионировано в .vscode/extensions.json:
{
"recommendations": ["esbenp.prettier-vscode" ]
}
Таким образом, любой, кто клонирует репозиторий проекта, сможет установить нужные расширения автоматически.
Комментарии (0)