Понимание критической важности безопасности PKI

Инфраструктура открытых ключей (PKI) является невидимым костяком доверия почти к каждому цифровому взаимодействию, от шифрования веб-трафика и подписания выпусков программного обеспечения до аутентификации пользователей и устройств с помощью смарт-карт или сертификатов безопасности транспортного уровня (TLS). Безопасность всего предприятия зависит от целостности его органов по сертификации (CAs). Если один корень CA скомпрометирован, модель доверия рушится. Злоумышленники могут подделывать токены аутентификации, дешифровать конфиденциальные сообщения или подписать вредоносный код с полными полномочиями организации. Учитывая эти высокие ставки, общее сканирование уязвимостей является абсолютной необходимостью для любой организации, заботящейся о безопасности. Эта статья предоставляет глубокое, процедурное руководство по выполнению тщательных оценок безопасности PKI, предназначенных для выявления недостатков конфигурации, криптографических слабостей и логических путей атаки, которые активно используют противники.

Тестирование на проникновение PKI: помимо базовых аудитов

Тестирование на проникновение PKI — это специализированная наступательная дисциплина безопасности, ориентированная на оценку положения безопасности всего жизненного цикла сертификата. Это включает в себя органы по сертификации, органы регистрации, криптографическое оборудование (HSM), шаблоны сертификатов, механизмы отзыва и приложения, которые полагаются на аутентификацию на основе сертификата. В отличие от стандартного обзора соответствия, тест на проникновение активно пытается обойти средства контроля безопасности, увеличить привилегии и продемонстрировать реальное влияние. В современных средах, особенно в тех, которые используют службы сертификатов Microsoft Active Directory (AD CS), это тестирование стало основным компонентом любой комплексной оценки безопасности Active Directory.

Отличия от сканирования уязвимостей

Автоматизированный сканер уязвимостей может идентифицировать недостающие патчи на сервере CA или проверить слабые наборы шифров. Однако опытный тестировщик проникновения идет гораздо дальше. Они изучают логическую конфигурацию шаблонов сертификатов, тест на небезопасные разрешения на регистрацию, анализируют криптографическую случайность и пытаются привязать несколько незначительных неверных конфигураций к полному захвату домена. Это руководство, логический анализ является основной ценностью специализированного тестирования проникновения PKI.

Предучастие: Скауп и правила участия

Перед началом любого технического тестирования необходимо установить четкий охват. Компоненты ИПК часто являются наиболее чувствительными системами в организации. Тестирование должно сбалансировать тщательность с операционной стабильностью.

  • Определите целевые ЦА: Определите, тестируете ли вы внутренний ЦА предприятия, общедоступный ЦА или управляемый облаком ИПК (например, AWS Private CA, Azure Key Vault Integrated CA).
  • Определение границ тестирования: Может ли команда по оценке напрямую взаимодействовать с корневой CA, или тестирование ограничено подчиненными CA и серверами выдачи?
  • Active vs. Passive Testing: Установите правила для попыток регистрации сертификатов. Активная регистрация против производственного ЦА может заполнить базу данных сертификатов или вызвать оповещения о безопасности. Некоторые тесты (например, атаки ретрансляции ESC8) требуют доступа на сетевом уровне и конкретных конфигураций протокола.
  • Обработка данных: Частные ключи и сертификаты CA, полученные во время тестирования, должны обрабатываться с особой тщательностью. Определите безопасные процедуры хранения и немедленного уничтожения после завершения тестирования.

Методология тестирования на проникновение PKI

Методический подход гарантирует, что ни один компонент не будет упущен из виду. Следующие этапы представляют собой стандартный рабочий процесс оценки безопасности ИПК.

1. Сбор и разведка информации

Первым шагом является картирование ландшафта PKI. Это включает в себя идентификацию всех CA, шаблонов сертификатов и полагающихся сторон в окружающей среде.

  • AD CS Discovery: В среде Active Directory такие инструменты, как Certipy или Certify, могут перечислить все объекты PKI по запросам LDAP. Это раскрывает серверы CA, шаблоны сертификатов, права регистрации и списки контроля доступа (ACL).
  • Журналы прозрачности сертификатов: Для общедоступных CA-файлов поиск журналов CT (с помощью таких инструментов, как ) может выявить все выданные сертификаты. Это помогает идентифицировать просроченные или неправильно выпущенные сертификаты, которым все еще можно доверять.
  • Сканирование открытых портов на серверах CA (обычно TCP 443 для веб-заполнения или TCP 445 для RPC / DCOM) показывает потенциальные поверхности атак для ретрансляционных атак (ESC8).

2. Обзор конфигурации органа сертификации

После обнаружения конфигурация самого ЦА тщательно изучается.

  • Контроль доступа: Кто имеет административные права или права на регистрацию в CA? Слишком разрешительные записи (например, «Пользователи домена», которым разрешено зарегистрироваться в чувствительных шаблонах) являются классическим находкой.
  • Политика выдачи: Проверка шаблонов с отключенным одобрением менеджера и необязательными авторизованными подписями. Эти шаблоны с «низкой безопасностью» часто являются вектором входа для повышения привилегий.
  • Криптографический провайдер: Убедитесь, что ЦА использует сильного, одобренного поставщика криптографических услуг (CSP) или поставщика хранения ключей (KSP). Наследственные поставщики, такие как Microsoft Strong Cryptographic Provider, имеют известные недостатки по сравнению с современными ключами, поддерживаемыми аппаратным обеспечением.

3. Атака AD CS (уязвимости ESC)

Наиболее важная часть современного внутреннего тестирования PKI вращается вокруг уязвимостей «ESC» (Escalation of Privilege), широко документированных исследовательской группой SpecterOps в их сертифицированном предзаказном документе .

  • ESC1: Наиболее распространенная и опасная неправильная конфигурация.Права на регистрацию, предоставленные малопривилегированным пользователям, Утверждение менеджера отключено, Авторизованные подписи, и шаблон позволяет запрашивать в запросе спецификацию альтернативного имени объекта .Злоумышленник может запросить сертификат для «Администратора» или «Контролера домена» и аутентифицировать как эту учетную запись.
  • ESC2: Аналогично ESC1, но шаблон использует «Любую цель» (подчиненный шаблон CA). Это может быть использовано для подписания запросов сертификатов для любого пользователя, эффективно создавая мошеннический CA.
  • ESC3: Включает неправильно настроенные шаблоны агентов регистрации.Если пользователь имеет права агента регистрации, и политика CA позволяет регистрировать кросс-лес или кросс-домены, злоумышленник может запросить сертификаты от имени любого пользователя.
  • ESC4: Слабый ACL на самом объекте шаблона сертификата.Злоумышленник с доступом к шаблону записи может изменить свои дескрипторы безопасности, чтобы ввести условия ESC1 или ESC2, даже если базовый шаблон безопасен.
  • ESC8: Эстафета атаки, не требующая неправильно настроенного шаблона. Она опирается на конечную точку веб-заполнения (NDES или CA Web Proxy) для ретрансляции аутентификации NTLM. Злоумышленник принуждает контроллер домена или другой сервер высокой ценности к аутентификации на свой реле, который затем пересылает хэш NTLM в CA для регистрации сертификата для этой машины. Это может привести к компрометации контроллера домена или сервера.

4. Криптографическая оценка силы

Анализ конкретных алгоритмов и методов управления имеет решающее значение для долгосрочной безопасности.

  • Ключевая длина: Убедитесь, что ключи CA являются по меньшей мере 2048-битными RSA (4096-бит рекомендуется для корневых CAs). Определите любые затяжные алгоритмы хеширования SHA-1 или MD5, которые криптографически сломаны и уязвимы для атак столкновения.
  • Модули безопасности аппаратного обеспечения: Оцените, хранятся ли ключи CA в HSM. Хранение ключей исключительно в программном обеспечении (на диске) делает их уязвимыми для эксфильтрации, если сервер скомпрометирован. HSM обеспечивают устойчивое к взлому хранение ключей и криптографическую разгрузку.
  • Генерация случайных чисел: Слабые генераторы случайных чисел (RNG) могут привести к предсказуемым ключам. Это было печально известно в инциденте с Debian OpenSSL. Тестеры могут анализировать образец выданных сертификатов на плохую энтропию (хотя это часто требует статистического анализа больших образцов).

5. Man-in-the-Middle (MITM) и Validation Bypass (Обход проверки)

PKI эффективен только в том случае, если полагающиеся стороны должным образом проверяют сертификаты. Проверка логики валидации является ключевой задачей.

  • Сертификат Pinning: Реализуются ли приложения для принятия любого сертификата, подписанного доверенным ЦА, или они закрепляют конкретные ключи?Слабое закрепление позволяет злоумышленнику заменить свой собственный сертификат.
  • Проверка отзыва: Проверка списков отзыва сертификатов (CRL) и протокола статуса онлайн-сертификатов (OCSP) выполняется? Неправильная настройка приложений часто полностью пропускает проверку отзыва, позволяя злоумышленникам использовать украденные, но отозванные сертификаты.
  • Протокол понижения: Может ли клиент быть обманут в принятии сертификата с более низкой прочностью или устаревшего протокола? Тестирование на полосовые атаки на соединения TLS/SSL может выявить уязвимости в корпоративных приложениях.

Основные инструменты для оценки безопасности PKI

Building a dedicated toolkit for PKI testing enables efficient and thorough assessments.

  • Сертификат: Современный инструмент Python, разработанный специально для эксплуатации и аудита AD CS. Он автоматизирует обнаружение уязвимостей ESC1-ESC8 и может запрашивать сертификаты, указывать SAN в запросах и даже выполнять часть ретрансляции NTLM ESC8.
  • OpenSSL: Швейцарский армейский нож криптографии. Используется для проверки деталей сертификата (]), генерации тестовых сертификатов, проверки цепочек и тестирования соединений TLS (]. Официальный сайт проекта OpenSSL предлагает обширную документацию для этих команд .
  • Burp Suite: Необходим для тестирования логики проверки TLS в веб-приложениях. Тестер может прокси-трафик через Burp и ввести самоподписанный или ненадежный сертификат CA, чтобы увидеть, правильно ли приложение отклоняет его или правильно проверяет цепочку сертификатов.
  • testssl.sh: Неоценимый инструмент для оценки конфигурации TLS/SSL любой службы. Он проверяет слабые наборы шифров, валидность сертификата, поддержку протокола (TLS 1.2 против 1.3) и общие недостатки реализации.
  • PowerShell (PSPKIAudit/ADCS Audit): Нативные модули PowerShell отлично подходят для быстрого аудита больших доменов. Модуль (предоставленный Microsoft или галереей PowerShell) может перечислить все шаблоны и их конфигурацию.

Анализ результатов и определение приоритетов риска

Отчетность является наиболее важной фазой взаимодействия. Технические выводы должны быть переведены в бизнес-риски.

  • Критический риск: Уязвимость ESC1, позволяющая немедленно получать привилегии администратора домена. Злоумышленник со стандартным доступом к пользователю может стать контроллером домена в течение нескольких минут. Это требует немедленного исправления.
  • Высокий риск: Слабое хранение криптографических ключей (ключи только для программного обеспечения) или пути ретрансляции ESC8, которые требуют дополнительной координации (координации аутентификации), но все же приводят к компромиссу сервера.
  • Средний риск: Пропущенные проверки отзыва в клиентских приложениях или использование подписей на основе SHA-1 на внутренних ЦА. Хотя они могут быть использованы в конкретных условиях, непосредственное воздействие ниже.
  • Информационные: CT журналы, раскрывающие внутренние имена хостов, или детали конфигурации прозрачности сертификата.

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

Реабилитация и укрепление лучших практик

Выявление слабых сторон - это только половина пути. Внедрение эффективных средств контроля имеет важное значение для долгосрочной устойчивости к ИПК.

Укрепление органа по сертификации

  • Изолировать CA: Корневая CA должна оставаться автономной и продублированной по воздуху для максимальной безопасности. Подчинённые CA должны быть размещены в сегменте защищенной сети со строгими правилами брандмауэра и минимальным административным доступом.
  • Используйте HSM: Разверните модули безопасности аппаратного обеспечения для всех уровней 3+ CA. Это защищает закрытые ключи от эксфильтрации, даже если сервер скомпрометирован.
  • Пейтч Регулярно: ЦА являются высокоценными целями. Убедитесь, что базовая серверная ОС и приложение ЦА исправлены для известных уязвимостей как можно скорее.

Защита сертификатов шаблоны

  • Отклоняемый запрос SAN на чувствительные шаблоны: Шаблоны для учетных записей с высокими привилегиями (администраторы доменов, администраторы) должны явно требовать авторизованных подписей и одобрения менеджера. Флаг SAN в схеме должен быть установлен на «Это критическое расширение», чтобы предотвратить изменение.
  • Шаблоны Enforce Schema Version 2: шаблоны версии 2 обеспечивают гранулированные настройки безопасности, включая возможность ограничения конструкции имени субъекта и требовать официального подписания.
  • Разрешения на ограниченную регистрацию: Разрешение на регистрацию в чувствительных шаблонах только для определенных групп безопасности (например, «Helpdesk» для пользовательских сертификатов, «Domain Admins» для администраторских сертификатов).

Сеть и укрепление протокола

  • Отключаемые пути ретрансляции NTLM: Включить подписание LDAP и связывание канала LDAP на контроллерах домена для предотвращения атак ретрансляции ESC8. Отключить аутентификацию NTLM на серверах CA, если это абсолютно не требуется для унаследованных клиентов.
  • Монитор CRL точек распространения (CDP) и OCSP ответчиков: Убедитесь, что они являются высокодоступными и правильно настроены. Неспособность в проверке отзыва может заставить приложения принять недействительные сертификаты.

Вывод: Непрерывная бдительность PKI

Тестирование на проникновение PKI не является одноразовым окном для проверки соответствия. Это непрерывная практика безопасности, которая должна развиваться наряду с угрозами и изменениями в вашей среде. По мере того, как организации мигрируют в облако и принимают архитектуры Zero-Trust, роль PKI расширяется, и так же расширяется поверхность атаки. Регулярно запланированные оценки - по крайней мере, ежегодно или после любого крупного изменения инфраструктуры, в сочетании с автоматизированным мониторингом для дрейфа конфигурации - являются лучшей защитой от атак на основе PKI. Приняв строгую, ориентированную на противника методологию тестирования и упрочнение приоритетов услуг сертификатов, организации могут обеспечить, чтобы их цифровая инфраструктура доверия оставалась непроницаемой. Фундаментальное руководство, предоставляемое органами стандартов, такими как NIST по управлению ключами, может служить долгосрочной дорожной картой для безопасных операций [ [NIST SP 800-57 Рекомендация по управлению ключами] .