Исследователь сообщает об уязвимости в браузерном редакторе VSCode от GitHub, которая при определенных обстоятельствах может привести к краже токена разработчика.
Проблема, о которой на этой неделе сообщил в своем блоге Аммар Аскар, по всей видимости, уже устранена владельцем GitHub компанией Microsoft. Однако она поднимает вопросы как о безопасности DevOps, так и об утверждении исследователя о том, что, поскольку Microsoft не относится серьезно к обнаружению багов, он может оправдать публикацию найденных им уязвимостей с минимальным уведомлением.
Во-первых, о баге: пользователи github.com могут не знать, но находясь в любом репозитории, они могут перейти в github.dev и его браузерную версию VSCode, просто изменив URL-адрес.
Зачем это делать? Потому что браузерная версия VSCode довольно мощная, как утверждает Аскар в своем блоге. «Вы можете просматривать все файлы в репозитории (даже если он приватный), отправлять pull-запросы и даже вносить коммиты».
Роб Эндерл, ИТ-консультант, возглавляющий Enderle Group, согласен, что такой переход в VSCode — «невероятно полезный тактический инструмент для быстрых задач. Просто нажав клавишу «.» в любом репозитории GitHub, вы мгновенно получаете интерфейс VS Code в браузере, не загружая локально гигабайты данных. Это идеально подходит для быстрого обзора PR, внесения быстрых правок в документацию или навигации по коду на лету, не прерывая рабочий процесс. Просто помните, что все это выполняется внутри песочницы браузера; нет ни вычислительного бэкенда, ни терминала, ни выполнения кода».
Для выполнения серьезных задач или фактической компиляции, добавил он, разработчику по-прежнему потребуется вычислительная мощность локальной рабочей станции или полноценная облачная среда, такая как Codespaces.
Проблема, по словам Аскара, заключается в том, что эта функциональность достигается за счет того, что github.com отправляет POST-запрос с OAuth-токеном на github.dev, который позволяет ему действовать от вашего имени в GitHub. «Токен не ограничен конкретным репозиторием, с которым вы взаимодействовали, что означает, что он имеет полный доступ ко всем остальным репозиториям, к которым у вас есть доступ», — написал он в блоге.
«Наличие этого токена и тот факт, что это веб-приложение обрабатывает почти всю нагрузку миллионной кодовой базы TypeScript VSCode, делает его отличной мишенью для тех, кто ищет ошибки в VSCode», — написал он.
Эксплойт
Аскар сообщил, что злоумышленник может установить расширение в репозитории с помощью Jupyter notebook — веб-приложения для создания и обмена вычислительными документами, которое имеет возможность устанавливать вредоносное локальное расширение рабочей области, минуя проверку доверия издателя. В своем доказательстве концепции Аскар заявил, что после запуска его полезной нагрузки недавно установленное расширение захватит токен GitHub API, выполнит запрос для получения приватных репозиториев, к которым имеет доступ разработчик, а затем выведет ответы и токен.
Эта уязвимость также существует в настольной версии VSCode, по словам Аскара, хотя ее сложнее использовать, поскольку злоумышленнику потребуется убедить жертву клонировать его репозиторий и открыть блокнот, содержащий полезную нагрузку скрипта webview. «Конечно», — добавил он, — «если вы [хакер] получите какую-либо другую XSS [атаку с межсайтовым скриптингом] в webview, которую сможете заставить жертву открыть, вы фактически получите полный RCE [удаленное выполнение кода] на ее компьютере».
В электронном письме он заявил, что эта уязвимость «одна из самых серьезных. Любой веб-сайт в Интернете мог перенаправить вас по ссылке github.dev, которая могла предоставить злоумышленнику токен для чтения и изменения ваших репозиториев кода. Если бы удалось убедить сопровождающего популярного программного проекта нажать на ссылку, можно было бы внести любые желаемые изменения в проект».
Это означает, по словам Эндерла, что «мы должны начать относиться к конечным точкам разработчиков со строгими, изолированными параметрами нулевого доверия, потому что мы явно не можем полагаться на самоуспокоенность поставщиков в вопросах нашей защиты».
Эта проблема подтверждает мысль о том, что никогда не следует переходить по ссылкам, если вы точно не знаете, куда они вас приведут, добавил Дуэйн Макдэниел, ведущий разработчик-адвокат в GitGuardian.
Краткое уведомление
Вот где все усложняется. Из-за неприятного опыта при раскрытии предыдущей уязвимости VSCode компании Microsoft — баг был исправлен, но Аскар не получил признания — на этот раз он дал GitHub всего один час на уведомление о том, что это новое открытие будет опубликовано. Microsoft применила то, что Аскар называет «временным» исправлением, исправлением, добавив подтверждение при открытии блокнотов в веб-версии VSCode и не разрешая пропускать требование о доверенном издателе с помощью команд.
[Связанный контент: Когда ответственное раскрытие становится неоплачиваемым трудом]
Этическая дилемма
Краткое уведомление Аскара поднимает этический вопрос: насколько заранее ответственный исследователь должен уведомить поставщика об уязвимости, прежде чем публично ее раскрыть?
В наши дни большинство специалистов по информационной безопасности согласны с тем, что уведомление должно быть предоставлено, иначе злоумышленник может быстро использовать брешь. Более того, исследователь рискует повредить своей репутации, если не будет предоставлено разумное уведомление. Опытные исследователи часто дают поставщикам не менее 30 дней на создание и распространение исправления.
Со своей стороны, поставщики часто создают программы Bug Bounty или сотрудничают с ними, чтобы вознаградить исследователей за их работу. К сожалению, некоторые поставщики не всегда указывают авторов или преуменьшают ущерб, который может нанести уязвимость. Фактически, в прошлом месяце Microsoft и известный исследователь кибербезопасности вступили в публичную перепалку по поводу одного такого предполагаемого инцидента.
Дисбаланс сил
На просьбу прокомментировать последнее открытие Аскара представитель Microsoft заявил: «Мы ценим критическую роль, которую сообщество исследователей безопасности играет в укреплении безопасности наших продуктов, услуг и более широкой технологической экосистемы. Хотя независимые исследователи определяют, когда и как публиковать свои выводы, мы по-прежнему стремимся оперативно оценивать сообщаемые проблемы, мобилизовать соответствующие инженерные ресурсы и ресурсы реагирования на инциденты безопасности, а также предоставлять смягчающие меры, руководства и средства защиты как можно быстрее, чтобы помочь защитить наших клиентов».
[Связанный контент: Является ли процесс раскрытия уязвимостей сам по себе сбоем? Как CISO остаются в неведении]
Существует баланс между координацией раскрытия информации с поставщиком программного обеспечения (CVD) и полным раскрытием информации, как сообщил нам Аскар. Но, добавил он, существует дисбаланс сил. «Исследователь безопасности может потратить бесчисленные часы на проблему, гарантируя, что он разработает хорошее доказательство концепции и предоставит все шаги для воспроизведения проблемы. С этим они надеются хотя бы получить признание своих усилий, которое они могут использовать для улучшения своего послужного списка в области безопасности или, в лучшем случае, получить денежное вознаграждение по программе Bug Bounty».
Однако, добавил он, «если поставщики безопасности не соблюдают свою часть сделки, публичное раскрытие информации — один из немногих вариантов, доступных исследователям безопасности (если они не хотят хранить свои уязвимости или продавать их на черном рынке). Это заставляет поставщика публично признать проблему безопасности и обычно приводит к гораздо более быстрому решению, чем любое частное общение».
Это, по словам Эндерла, создает проблемы для предприятий: «Когда бюрократия поставщиков наказывает ответственное раскрытие информации, это отчуждает сообщество безопасности и вынуждает к публичным сбросам уязвимостей нулевого дня, в конечном итоге оставляя корпоративных клиентов расплачиваться».
Эта статья изначально появилась на InfoWorld.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Howard Solomon
