Прозрачные картинки крадут ваши ключи: как GitHub Copilot стал шпионским инструментом

Исходный инцидент показывает: даже инструменты, созданные чтобы помогать разработчикам, могут стать каналом утечки секретов, если их использовать неправильно. Исследователи из Legit Security продемонстрировали практический сценарий атаки на GitHub Copilot, при котором конфиденциальные строки из приватных репозиториев (например, ключи доступа AWS) извлекаются через хитроумную визуальную эксфильтрацию.

Краткое описание уязвимости

GitHub Copilot способен подгружать изображения, связанные с обрабатываемым контентом. Атака использует это поведение вместе с возможностью слать в pull-request скрытые HTML-комментарии вида . Злоумышленник формирует набор однопиксельных прозрачных PNG-изображений, где каждая картинка соответствует отдельному символу (букве, цифре или спецсимволу).

В теле pull-request в скрытом комментарии даётся инструкция боту: найти в репозиториях строки, содержащие, например, AWS_KEY, и вывести их не как текст, а "изобразить" последовательностью картинок. Для сопоставления символов с картинками в комментарии приводится таблица соответствий. Поскольку изображения прозрачные, мейнтейнер не увидит визуальной аномалии, а злоумышленник восстановит ключи, анализируя логи запросов к серверу изображений.

Технический обход защит (CSP и Camo)

Ограничения Content Security Policy на GitHub позволяют подгружать изображения только с серверов GitHub. Чтобы обойти это, атакующий проксирует ресурсы через сервис GitHub Camo — промежуточный узел, который ретранслирует внешние картинки и делает их доступными под доменом camo. githubusercontent.com. Через REST API GitHub attacker заранее добавляет и верифицирует пути в Camo, после чего ссылки в таблице соответствий указываются на https://camo.githubusercontent.com/<хэш_картинки>. Это позволяет скрыто загружать нужные пиксели и маскировать источник.

Таблица "Сравнение"

Сравним ключевые элементы атаки и типовую защиту.

1. Атака: визуальная эксфильтрация через прозрачные изображения.

2. Защита: строгая CSP + проверка содержимого pull-request.

Советы шаг за шагом (HowTo)

1. Проанализируйте текущую политику CSP репозиториев и сократите разрешённые домены для изображений.

2. Настройте серверную проверку вставляемых в PR ссылок — блокируйте camo-прокси или требуйте подписи источника.

3. Внедрите сканер комментариев в CI: ищите шаблоны вроде "visualize", "image map", таблиц соответствий символ→URL.

4. Ограничьте права ботов: не разрешайте автоматическим ассистентам читать приватные репозитории без отдельного аудита.

5. Введите мониторинг аномального трафика к Camo/другим прокси: резкие серии запросов к маленьким файлам — красный флаг.

Ошибка → Последствие → Альтернатива

1. Ошибка: доверять автоматическому выводу Copilot без проверки. → Последствие: утечка секретов. → Альтернатива: требовать ручного подтверждения чувствительных операций и ревью.

2. Ошибка: разрешать произвольные внешние изображения в README/PR. → Последствие: канал для эксфильтрации. → Альтернатива: блокировать сторонние прокси и использовать белый список хостов.

3. Ошибка: хранить ключи в коде. → Последствие: любая автоматизация, читающая код — риск. → Альтернатива: использовать секрет-менеджеры (Vault, AWS Secrets Manager) и ротацию ключей.

"А что если…"

…бот не может читать приватные репозитории?

Если у ассистента нет прав — метод не сработает. Но атака требует, чтобы бот выполнял анализ присланного PR и имел доступ к контексту; потому главный вектор — неправильно настроенные разрешения.

…лог сервера недоступен атакующему?

Если логи Camo не публичны, восстановление возможно через компрометацию прокси или анализ запросов на стороне клиента. Поэтому мониторинг и защита прокси критичны.

Таблица "Плюсы и минусы"

FAQ (минимум 3 вопроса)

Как выбирать настройки прав для ботов?

Ограничьте доступ ботов принципом наименьших привилегий: права только на конкретный репозиторий/ветку и только на чтение тех частей, которые необходимы.

Сколько стоит внедрить защиту?

Стоимость зависит от масштаба: простые правила CSP и парсер комментариев — низкая; полноценный SIEM и анализ трафика — выше. Начните с базовой валидации и ротации секретов.

Что лучше для хранения ключей — файлы в репозитории или секрет-менеджер?

Секрет-менеджер однозначно лучше: он обеспечивает аудит, ротацию и доступ по политике — это минимизирует риск утечки.

Мифы и правда

1. Миф: "если ключа нет в явном тексте, значит всё в порядке". Правда: ключи могут передаваться косвенно или извлекаться из бинарных данных/логов.

2. Миф: "CSP решит все проблемы с внешними ресурсами". Правда: неправильная конфигурация или доверие прокси (Camo) делают CSP бесполезной.

3. Миф: "прозрачные изображения — безвредны". Правда: они могут служить каналом передачи данных.

Сон и психология

Утечки и инциденты сильно бьют по командам: ночные дежурства, постоянный стресс и потеря доверия. Важно планировать ротацию обязанностей, выделять время на отдых после инцидента и проводить разборы инцидентов в духе "что сломалось и как предотвратить", а не личностных обвинений.

Три интересных факта

1. Однопиксельные изображения уже использовались для трекинга пользователей в вебе; тут идея адаптирована для передачи данных.

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

3. Визуальная эксфильтрация сложнее обнаруживается традиционными DLP-системами, которые фокусируются на текстовых паттернах.

Исторический контекст

1. Ранние веб-трекеры использовали tiny-images (1x1) для слежения; это предшественник техники.

2. Появление ассистентов кода расширило поверхность атаки: ботам дают доступ к контексту проектов.

3. Параллельно развивались прокси-сервисы (типа Camo) для приватности, которые при определённых условиях можно перенастроить в инструмент злоумышленника.