Недавно мы получили сообщение об ошибке, касающееся ключа подписи GPG, используемого для pkg.cloudflareclient.com, репозитория пакетов Linux для наших продуктов Cloudflare WARP. В отчете говорилось, что этот закрытый ключ был раскрыт. С тех пор мы поменяли этот ключ и предпринимаем шаги, чтобы подобная проблема не повторилась. Прежде чем продолжить, если вы являетесь пользователем Cloudflare WARP для Linux, следуйте этим инструкциям, чтобы изменить открытый ключ Cloudflare GPG, которому доверяет ваш менеджер пакетов. Это касается только пользователей WARP, которые установили WARP в Linux. Это не влияет на клиентов Cloudflare других наших продуктов или пользователей WARP на мобильных устройствах.
Но мы также поняли, что влияние неправильно защищенного закрытого ключа может иметь последствия, выходящие за рамки одного стороннего репозитория. В оставшейся части этого блога показано, как повысить безопасность apt со сторонними репозиториями.
Неожиданное воздействие
Сначала мы думали, что открытый ключ подписи может быть использован злоумышленником только для подделки пакетов, распространяемых через наш репозиторий пакетов. Однако, изучая влияние на платформы Debian и Ubuntu, мы обнаружили, что наши инструкции устарели и небезопасны. Фактически, мы обнаружили, что большинство репозиториев пакетов Debian в Интернете предоставляют такие же плохие рекомендации: загрузите ключ GPG с веб-сайта, а затем либо направьте его напрямую в apt-key, либо скопируйте его в /etc/apt/trusted.gpg.d/. Этот метод добавляет ключ в качестве доверенного корня для установки программного обеспечения из любой источник. Чтобы понять, почему это проблема, мы должны понять, как apt загружает и проверяет пакеты программного обеспечения.
Как apt проверяет пакеты
На заре Linux специалисты по сопровождению пакетов хотели убедиться, что пользователи могут доверять тому, что программное обеспечение, устанавливаемое на их машины, поступает из надежного источника.
У Apt есть список мест, из которых можно получить пакеты (источники) и метод проверки этих источников (доверенные открытые ключи). Исторически ключи хранились в одном файле связки ключей: /etc/apt/trusted.gpg. Позже, когда сторонние репозитории стали более распространенными, apt также мог заглянуть внутрь /etc/apt/trusted.gpg.d/ для отдельных ключевых файлов.
Что происходит при запуске apt update? Сначала apt извлекает из каждого источника подписанный файл с именем InRelease. Некоторые серверы вместо этого предоставляют отдельные файлы выпуска и подписи, но служат той же цели. InRelease — это файл, содержащий метаданные, которые можно использовать для криптографической проверки каждого пакета в репозитории. Что важно, он также подписан закрытым ключом владельца репозитория. В рамках процесса обновления apt проверяет, что файл InRelease имеет действительную подпись и что подпись была создана доверенным корнем. Если все прошло успешно, локальный кеш пакетов обновляется содержимым репозитория. Этот кеш напрямую используется при установке пакетов. Цепочка подписанных файлов InRelease и криптографических хэшей гарантирует, что каждый загруженный пакет не был поврежден или подделан в процессе.
Типичный сторонний репозиторий сегодня
Для большинства пользователей Ubuntu / Debian сегодня добавление стороннего репозитория выглядит так на практике:
- Добавить файл в
/etc/apt/sources.list.d/сообщая apt, где искать пакеты. - Добавьте открытый ключ gpg в
/etc/apt/trusted.gpg.d/, возможно, через apt-key.
Если на втором шаге используется apt-key, команда обычно выдает предупреждение об устаревании, в котором вам предлагается не использовать apt-key. На это есть веская причина: добавление такого ключа доверяет ему любой репозиторий, а не только источник из первого шага. Это означает, что если закрытый ключ, связанный с этим новым источником, будет скомпрометирован, злоумышленники могут использовать его, чтобы обойти проверку подписи apt и установить свои собственные пакеты.
Как бы выглядел этот тип атаки? Предположим, у вас есть стандартная установка Debian со списком источников по умолчанию.1:
deb http://deb.debian.org/debian/ bullseye main non-free contrib
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
В какой-то момент вы установили доверенный ключ, который позже был раскрыт, и у злоумышленника есть закрытый ключ. Этот ключ был добавлен вместе с источником, указывающим на https, предполагая, что даже если ключ будет взломан, злоумышленнику также придется взломать шифрование TLS, чтобы установить программное обеспечение по этому маршруту.
Вы наслаждаетесь горячим напитком в местном кафе, где кто-то гнусный сумел взломать роутер без вашего ведома. Они могут перехватывать http-трафик и изменять его без вашего ведома. На вашем ноутбуке запускается скрипт автообновления. apt update. Злоумышленник выдает себя за deb.debian.org, и поскольку по крайней мере один источник настроен на использование http, злоумышленнику не нужно взламывать https. Они возвращают измененный файл InRelease, подписанный скомпрометированным ключом, что указывает на то, что доступно более новое обновление пакета bash. apt получает новый пакет (опять же от злоумышленника) и устанавливает его от имени пользователя root. Теперь у тебя большая проблема2.
Лучший способ
Кажется, что большинству людей предлагается создавать сторонние репозитории Debian неправильно. Что, если бы вы могли сказать apt доверять этому ключу GPG только для определенного источника? Это, в сочетании с использованием https, значительно снизит влияние взлома ключа. Оказывается, есть способ сделать это! Вам нужно будет сделать две вещи:
- Убедитесь, что ключ не в
/etc/apt/trusted.gpgили/etc/apt/trusted.gpg.d/больше. Если ключ является отдельным файлом, самый простой способ сделать это — переместить его в/usr/share/keyrings/. Убедитесь, что файл принадлежит пользователю root и только root может писать в него. Этот шаг важен, потому что он не позволяет apt использовать этот ключ для проверки всех репозиториев в списке источников. - Измените исходный файл в
/etc/apt/sources.list.d/сообщая apt, что этот конкретный репозиторий может быть «подписан» определенным ключом. Когда вы закончите, линия должна выглядеть так:
deb [signed-by=/usr/share/keyrings/cloudflare-client.gpg] https://pkg.cloudflareclient.com/ bullseye main
Некоторые списки источников содержат другие метаданные, указывающие, что источник действителен только для определенных архитектур. В таком случае просто добавьте пробел посередине, например:
deb [amd64 signed-by=/usr/share/keyrings/cloudflare-client.gpg] https://pkg.cloudflareclient.com/ bullseye main
Мы обновили инструкции по нашим собственным репозиториям для клиента WARP и Cloudflare, добавив эту информацию, и надеемся, что другие последуют нашему примеру.
Если ты бежишь apt-key list на вашем компьютере вы, вероятно, найдете несколько ключей, которым доверяют гораздо больше, чем следовало бы. Теперь вы знаете, как их исправить!
Для тех, у кого есть собственный репозиторий, сейчас отличное время для ознакомления с инструкциями по установке. Если в ваших инструкциях пользователям предлагается скрутить файл открытого ключа и передать его прямо в sudo apt-key, возможно, есть более безопасный способ. Пока вы там, убедитесь, что репозиторий пакетов поддерживает https — отличный способ добавить дополнительный уровень безопасности (а если вы размещаете свой трафик через Cloudflare, его легко настроить и бесплатно. Вы можете следить за этим сообщением в блоге, чтобы узнайте, как правильно настроить Cloudflare для кеширования пакетов Debian).
1Дистрибутивы на основе RPM, такие как Fedora, CentOS и RHEL, также используют общее надежное хранилище GPG для проверки пакетов, но, поскольку они обычно используют https по умолчанию для получения обновлений, они не уязвимы для этой конкретной атаки.
2Описанная выше атака требует активного атакующего в сети. Если вы используете клиент WARP или Cloudflare для команд для туннелирования трафика в Cloudflare, ваш сетевой трафик не может быть изменен в локальных сетях.
