На які валідатори впливає додатковий кореневий сертифікат?

Ви знаходите кореневий сертифікат, якого там не повинно бути, і перше питання — чию особу він може підробити. Чесна відповідь залежить від того, яка програма звертається до цього сховища і як ваш VPN перевіряє свій шлюз. Браузер, менеджер пакетів і клієнт VPN із закріпленим відбитком не обов'язково поділяють одне й те саме рішення про довіру. Складіть карту валідаторів, перш ніж визначати обсяг.

Корінь у системному сховищі — не універсальний ключ

Встановлення кореня робить сертифікати, підписані цим ключем, прийнятними для програм, які використовують уражене сховище. Це не робить їх автоматично прийнятними всюди, бо деякі застосунки постачаються з власним набором або перевіряють закріплене значення. Це також не доводить, що хтось виконав код на машині; зміна довіри — одна з кількох можливостей. Розглядайте сертифікат як знахідку, яку треба обмежити, а не як всю подію.

Сховище не менш важливе за сертифікат: набір рівня користувача і якір системного рівня досягають різних споживачів.

Складіть карту кожного валідатора та джерела його довіри

Запишіть кожен компонент, який перевіряє сертифікати для уражених робочих процесів: браузер, менеджер пакетів, поштовий клієнт, VPN. Потім знайдіть джерело довіри, яке читає кожен із них.

ls /usr/local/share/ca-certificates
trust list | grep -i -E "vpn|corp"

Лістинг каталогу показує якорі, додані локально в системах типу Debian, а список довіри показує, що системне сховище наразі надає. Браузер із власним сховищем там не з'явиться, а застосунок на Java або Python може використовувати ще інший набір. Запишіть, які записи очікуються, а які ні, спираючись на відбиток, а не лише на відображуване ім'я. Цей список потрібен фахівцю з реагування на інциденти, перш ніж щось видаляти.

Перевірте власну перевірку партнера в самому VPN

VPN з приватним CA або явним відбитком оцінює шлюз за власною конфігурацією. Порівняйте те, що очікує клієнт, із тим, що представляє шлюз.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -subject

Вивід дає відбиток SHA-256 і суб'єкт сертифіката, який представляє кінцева точка, і їх можна порівняти з налаштованим значенням. OpenVPN має опцію відбитка партнера, яка виконує це порівняння для тунелю, не вимагаючи, щоб системне сховище приймало підписувача. Ця незалежність корисна для тунелю й нічого не каже про браузер. Вона також не допоможе, якщо очікуваний відбиток було скопійовано із підозрілого з'єднання від самого початку.

Обмежте інцидент за межами сертифіката

Скористайтеся процедурою власника пристрою, щоб видалити несанкціоновані якорі та знайти зміни, які зазвичай їх супроводжують: нові служби, змінені клієнти, змінені налаштування проксі. На керованій машині підтвердьте законну конфігурацію, перш ніж видаляти матеріали, від яких залежить інше програмне забезпечення. Для кожного валідатора запишіть, звідки походить його довіра, яку особу він очікує і як ви підтвердили, що поточна конфігурація правильна. Робочий тунель після очищення — це одне спостереження, а не доказ того, що кінцева точка чиста.

Потім повторно перевірте робочі процеси, які використовували сховище, бо видалення якоря може зламати внутрішню службу, що законно покладалася на нього. Відновлення завершено, коли очікувані відносини довіри працюють, а неочікувані — ні.