Разбор вопроса 2 дневного сеанса экзамена специалиста по обеспечению информационной безопасности, осень 5-го года Рэйва — файлы уносят через гостевой Wi-Fi

Подключение USB запретили. Сохранение файлов на локальный диск запретили. Обмен с веб-почтой и облачным хранилищем, которые компания не одобрила, перекрыли. Вложения файлов в электронную почту запретили. Внутренний файловый сервер упразднили.

Тем не менее рабочие файлы унести можно.

Вопрос 2 дневного сеанса осеннего экзамена специалиста по обеспечению информационной безопасности 5-го года Рэйва (2023) ставит сцену в компании M швейной отрасли, которая уже сделала всё перечисленное, и просит найти оставшиеся дыры¹. Это вторая статья серии после разбора вопроса 1 (хранимый XSS); область смещается с веб-приложения на внутреннюю сеть и аутентификацию устройств.

Если вопрос 1 спрашивал «где обошли меры, выстроенные перед веб-приложением», вопрос 2 спрашивает «какой объём дизайн мер на самом деле собирался защищать». Ни одна мера компании M не ошибочна. Но проверьте по одной границу, которую каждая должна была покрыть, — сразу за ней оставлено открытое пространство.

Что даёт эта статья — помимо образцов ответов и их оснований по каждому подвопросу — набор практических контрольных точек, которые можно брать в работу как есть, по трём областям: беспроводная сеть, сертификаты сервера, ограничение по исходному IP-адресу. Тем, кто готовится к экзамену, можно читать разделы по подвопросам; тем, кому нужна только практическая перспектива, смысл держится, если начать сразу с глав 11 и 12.

1. Сначала вывод

• Дыра была переговорная. Компания M запрещала принос лично принадлежащих ПК на территорию, но запрет покрывал только рабочие помещения — переговорная была вне. До переговорной доходят и беспроводная сеть сотрудников, и гостевая.
• У сотрудника два пути выноса: подделать MAC-адрес и войти в беспроводную сеть сотрудников и просто подключиться к гостевой беспроводной сети. Второй гораздо проще — нужен только предварительно общий ключ, который раздают гостям.
• Облачное хранилище (служба B) было ограничено «вход только с глобального IP-адреса компании M». Но трафик гостевой беспроводной сети тем же NAT преобразуется в тот же глобальный IP-адрес, поэтому ограничение проходит насквозь. Ограничение по исходному IP — настройка, которая разрешает не устройство, а всех, кто делит выход.
• Поддельную AP плюс поддельный сайт внешнего атакующего останавливает проверка сертификата сервера. Работают две проверки: «выдан ли доверенным удостоверяющим центром» и «совпадает ли имя сервера в сертификате с тем, к которому подключаются». По комментарию IPA к оцениванию доля верных ответов на подвопрос об этих двух пунктах была низкой.
• Даже при опечатке http:// снова получается ошибка сертификата, потому что HSTS перед соединением подменяет на HTTPS. И на узле, где HSTS действует, пользователю нельзя предлагать обойти предупреждение и идти дальше.
• Законная функция общего доступа к файлам тоже путь выноса: достаточно указать свой личный адрес электронной почты как внешнего получателя. Одобрение руководителя было, но часть руководителей адресата не проверяла.
• Столпы мер три. Беспроводную сеть сотрудников перевести на EAP-TLS с аутентификацией клиентским сертификатом на каждое устройство, закрытый ключ держать в TPM, чтобы его нельзя было вынести с рабочего ПК; гостевую беспроводную сеть отделить от сети компании M (или развести исходящий глобальный IP); и удалить VLAN, правила фильтрации и SSID, которыми больше не пользуются.

Карта знаний этой статьи

Статья на материале вопроса 2 дневного сеанса осеннего экзамена специалиста по обеспечению информационной безопасности 5-го года Рэйва разбирает ревью дизайна вокруг беспроводной сети и сертификата сервера. WPA2-PSK, при котором все делят один ключ, слаб тем, что любой, кто ключ знает, может поднять поддельную AP (evil twin), неотличимую от настоящей; но при проверке сертификата сервера и HSTS вход на поддельный сайт не складывается. При выносе сотрудником против подделки MAC-адреса мера — EAP-TLS с клиентским сертификатом и RADIUS, а против обхода ограничения по исходному IP через выход NAT, который делят несколько сетей, — отделение гостевой сети. Ключ, который делает аутентификацию сертификатом реально работающей, — хранить закрытый ключ в TPM так, чтобы его нельзя было вынести.

flowchart LR
    accTitle: Карта знаний вопроса 2 дневного сеанса экзамена специалиста по обеспечению информационной безопасности, осень 5-го года Рэйва (беспроводная сеть и сертификат сервера)
    accDescr: Рисунок, показывающий, как слабость WPA2-PSK из-за общего ключа ведёт к подделке MAC и атаке evil twin, как проверка сертификата сервера и HSTS не дают войти на поддельный сайт, как EAP-TLS с RADIUS и закрытым ключом в TPM реализуют поустройственную аутентификацию, и связь пределов ограничения по исходному IP, который делит NAT, с их исправлением.
    wpa2_psk["WPA2-PSK"]
    eap_tls["EAP-TLS"]
    evil_twin["атака evil twin («злой близнец»)"]
    phishing["фишинг"]
    mac_address_filtering["фильтрация MAC-адресов"]
    mac_address_spoofing["подделка MAC-адреса"]
    server_certificate_validation["проверка сертификата сервера"]
    certificate_chain["цепочка сертификатов"]
    root_ca["корневой сертификат УЦ"]
    certificate_revocation_check["проверка отзыва сертификата"]
    trust_anchor_risk["риск злоупотребления точкой доверия"]
    hsts["HSTS (HTTP Strict Transport Security)"]
    hsts_preload_list["список предзагрузки HSTS"]
    client_certificate["клиентский сертификат"]
    radius["RADIUS"]
    ieee_802_1x["IEEE 802.1X (EAP over LAN)"]
    network_policy_server["сетевой сервер политик (NPS)"]
    private_key["закрытый ключ"]
    tpm["TPM"]
    key_exfiltration_risk["риск выноса закрытого ключа"]
    shared_egress_ip_bypass["обход ограничения по исходному IP через общий исходящий IP"]
    nat["NAT (преобразование сетевых адресов)"]
    guest_network_isolation["отделение гостевой сети"]
    unused_config_cleanup["удаление ставших ненужными настроек"]
    source_ip_restriction["ограничение по исходному IP-адресу"]
    wpa2_psk -->|"может вызвать"| evil_twin
    evil_twin -.->|"может вызвать"| phishing
    mac_address_filtering -->|"не рекомендуется"| mac_address_spoofing
    eap_tls -->|"рекомендуется для"| mac_address_spoofing
    server_certificate_validation -.->|"предотвращает"| phishing
    server_certificate_validation -->|"использует"| certificate_chain
    server_certificate_validation -->|"использует"| root_ca
    server_certificate_validation -.->|"использует"| certificate_revocation_check
    root_ca -.->|"может вызвать"| trust_anchor_risk
    hsts -.->|"предотвращает"| phishing
    hsts -->|"требует"| server_certificate_validation
    hsts_preload_list -.->|"снижает"| evil_twin
    eap_tls -->|"использует"| client_certificate
    eap_tls -.->|"использует"| radius
    eap_tls -.->|"использует"| ieee_802_1x
    network_policy_server -->|"реализует"| radius
    client_certificate -->|"требует"| private_key
    private_key -.->|"хранится в"| tpm
    tpm -.->|"предотвращает"| key_exfiltration_risk
    shared_egress_ip_bypass -.->|"требует"| wpa2_psk
    nat -->|"может вызвать"| shared_egress_ip_bypass
    guest_network_isolation -->|"предотвращает"| shared_egress_ip_bypass
    guest_network_isolation -->|"должен предшествовать"| unused_config_cleanup
    source_ip_restriction -.->|"несовместимо с"| nat

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 24, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. О материале — источник и как он здесь используется

Разбираемый вопрос:

Источник: осенний экзамен специалиста по обеспечению информационной безопасности 5-го года Рэйва, дневной сеанс, вопрос 2

IPA указывает, что, кроме случаев, особо предусмотренных законом, для использования ранее опубликованных экзаменационных вопросов разрешение и плата за использование не требуются. Авторское право при этом не отказывается: требуется указывать источник в форме «финансовый год, сессия, категория экзамена, временной слот, номер вопроса и т. д.» и, если вопрос изменён, отмечать и это².

Эта статья не воспроизводит рисунки и таблицы из буклета вопроса дословно. Где схема нужна, чтобы объяснить механизм, она заменена упрощённой схемой и кратким изложением, написанными нами. Формулировки подвопросов и образцы ответов тоже даны в сжатом виде. Оригиналы буклета вопроса, образцов ответов и комментария к оцениванию можно бесплатно скачать с сайта IPA; рекомендуем держать их открытыми рядом с этой статьёй^{1 3 4}.

Соответствие подвопросов этой статье

Можно начинать читать с того подвопроса, который хотите разобрать.

Как в буклете вопроса и как здесь

Чтобы можно было сверять с оригиналом, сводим, что и как обработано.

3. Сцена задачи — что компания M «уже делала»

Компания M — дочерняя компания L, швейная отрасль, 100 сотрудников. Офисное здание выходит на оживлённую улицу в центре Токио. Эта фраза потом сработает.

В прошлом году сотрудник сохранил на USB секретный файл дизайна товара с внутреннего файлового сервера и унёс его конкуренту. По указанию материнской компании L идёт пересмотр мер безопасности. Уже сделанные три пункта такие.

• На выданные сотрудникам ноутбуки (далее — рабочие ПК) поставили ПО защиты от утечек и задали: запрет подключения внешних носителей вроде USB; запрет сохранения файлов на локальный диск, кроме установки ПО; перекрытие обмена с веб-почтой и облачным хранилищем, которые компания не одобрила; запрет установки ПО, которое компания не одобрила; запрет вложений файлов при отправке электронной почты
• Место хранения рабочих файлов свели в одно облачное хранилище, которым пользовались и раньше (далее — служба B), и пересмотрели настройки
• Внутренний файловый сервер упразднили

Прошлое происшествие шло путём «внутренний файловый сервер» → «USB», поэтому закрыли оба конца пути. Логика держится.

Сетевая конфигурация

В офисном здании есть рабочие помещения и переговорная. В рабочих помещениях работает беспроводная сеть сотрудников; в переговорной — и сотрудники, и гости. Проектор переговорной используют, подключая принесённое гостем устройство (ПК, планшет, смартфон гостя) или рабочий ПК к гостевой беспроводной сети.

В объёме, нужном для объяснения, схема такая.

flowchart LR
    accTitle: Сетевая конфигурация компании M
    accDescr: Гостевая беспроводная сеть, беспроводная сеть сотрудников и сеть серверов через один NAT брандмауэра преобразуются в один глобальный IP и выходят к службе B
    subgraph M["Внутренняя сеть компании M"]
        direction TB
        G["Гостевая беспроводная сеть<br/>192.168.10.0/24<br/>(только AP переговорной)"]
        E["Беспроводная сеть сотрудников<br/>192.168.20.0/24<br/>(рабочие помещения и переговорная)"]
        S["Сеть серверов<br/>192.168.30.0/24<br/>DHCP, DNS, каталог"]
        FW["Брандмауэр<br/>NAT преобразует источник<br/>в один глобальный IP"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["Служба B<br/>(облачное хранилище)"]
    FW --> I["Интернет"]

Рис. 1: Гостевая сеть, сеть сотрудников и сеть серверов через один NAT брандмауэра выходят в интернет как один глобальный IP.

Спецификации, которые нужно держать:

И три правила безопасности. Вынос рабочего ПК за пределы компании запрещён, принос лично принадлежащих ПК, планшетов, смартфонов и т. п. в рабочие помещения запрещён, вынос рабочих файлов за пределы компании запрещён любым способом, кроме функции общего доступа службы B.

Заметили, что во втором правиле написано «в рабочие помещения»? Переговорная не названа.

Как движется эта задача

Г-жа Y из ИТ при поддержке г-на S, специалиста по обеспечению информационной безопасности (зарегистрированный RISS) материнской компании L, проверяет, достаточны ли меры против выноса файлов из службы B. Двое разделяют рассмотрение на вынос внешним атакующим и вынос сотрудником. Подвопрос 1 — первое, подвопрос 2 — второе, подвопрос 3 — проект мер.

4. Поддельный Wi-Fi и поддельный сайт — подвопросы 1(1)(2)

Первое, что поднимает г-жа Y, — сценарий, в котором гость, который уже пользовался гостевой беспроводной сетью, как атакующий подключается к гостевой беспроводной сети рядом с компанией M и обращается к службе B.

Сценарий складывается потому, что способ аутентификации беспроводной сети — WPA2-PSK. PSK (Pre-Shared Key, предварительно общий ключ) — как следует из имени, способ, при котором все делят один и тот же ключ. Предварительно общий ключ гостевой беспроводной сети как раз для того, чтобы сообщить гостю. Сообщили однажды — отозвать знание этого человека в будущем нельзя (кроме как сменить у всех). Плюс здание выходит на оживлённую улицу, поэтому радио доходит и снаружи.

Ответ г-на S ясен. Чтобы войти в службу B, нужны [a] идентификатор пользователя и [b] пароль. Это образец ответа подвопроса 1(1) (порядок любой). Само подключение к беспроводной сети не означает вход в службу B.

Поддельная AP и поддельный сайт

Тогда г-жа Y идёт на шаг глубже. Что, если подготовить поддельную AP с теми же настройками, что у AP гостевой беспроводной сети, и поддельный сайт с тем же URL, что у службы B, подкрутить DNS и украсть идентификатор пользователя и пароль. Если поставить поддельную AP рядом с компанией M, сотрудник компании M может по ошибке подключить рабочий ПК к поддельной AP, обратиться к службе B, попасть на поддельный сайт и войти.

Так называемый evil twin («злой близнец»). Если поднять AP с тем же SSID и тем же предварительно общим ключом, что у гостевой беспроводной сети, со стороны устройства её не отличить от настоящей. В WPA2-PSK устройство про устройство AP может проверить только «знает ли тот же предварительно общий ключ». AP, которая ключа не знает, процедуру подключения не завершит; наоборот, любой, кто ключ знает, может стать «настоящей AP». Раз ключ раздают гостям, его нужно считать розданным и атакующему.

Ответ г-на S и здесь ясен. Когда сотрудник пытается обратиться к поддельному сайту по HTTPS, вместе с сообщением о том, что соединение небезопасно, в веб-браузере отображается один или несколько из следующих четырёх пунктов — в зависимости от сертификата сервера, которым пользовался поддельный сайт.

• Этот сертификат сервера выдан не доверенным удостоверяющим центром (пропуск c)
• Имя сервера, указанное в этом сертификате сервера, отличается от имени сервера, к которому подключаются (пропуск d)
• Этот сертификат сервера отозван
• Срок действия этого сертификата сервера истёк

Нижние два в буклете вопроса написаны с самого начала; верхние два (пропуски c и d, каждый до 40 знаков, порядок любой) — ответ подвопроса 1(2).

sequenceDiagram
    accTitle: Поддельную AP и поддельный сайт останавливает проверка сертификата
    accDescr: Когда сотрудник соединяется по HTTPS через поддельную AP, появляется ошибка — выдан не доверенным УЦ или имя сервера не совпадает, — и экран входа не показывается
    autonumber
    participant U as Рабочий ПК сотрудника
    participant F as Поддельная AP и поддельный сайт<br/>(атакующий)
    participant B as Служба B (настоящая)

    Note over F: Поднять AP с тем же SSID и<br/>тем же предварительно общим ключом, что у гостевой беспроводной сети
    U->>F: По ошибке подключиться к поддельной AP
    Note over F: Подкрутить DNS и направить<br/>доменное имя службы B на поддельный сайт
    U->>F: Соединение по HTTPS с URL службы B
    F-->>U: Сертификат сервера поддельного сайта
    Note over U: Проверка не проходит<br/>· выдан не доверенным УЦ<br/>· имя сервера в сертификате отличается от адресата
    Note over U: Показать ошибку о небезопасном соединении<br/>экран входа не показывается
    Note over U,B: С настоящей службой B<br/>обмена нет вовсе

Рис. 2: Доступ по HTTPS через поддельную AP падает на проверке сертификата сервера; экран входа не появляется.

На что смотрит проверка сертификата

Комментарий к оцениванию об этом подвопросе пишет так.

Подвопрос 1(2) дал низкую долю верных ответов. Даже если атакующий подготовил поддельный сайт, при доступе по HTTPS проверка сертификата сервера не проходит. Проверка сертификата сервера — базовое знание для обеспечения безопасности обмена, поэтому нужно хорошо понимать, включая то, какие именно пункты проверяются.

«Ошибка сертификата будет» знают, но разложить, что именно проверили и почему не прошло, на четыре пункта смогли немногие. Четыре пункта рис. 2, с точки зрения «для какой проверки каждый», выглядят так.

Со стороны атакующего верхние два — непреодолимая стена. Самоподписанный падает на первом; даже законно получив бесплатный сертификат на свой домен (например b-service.example.net), адресат — домен службы B, поэтому падает на втором. Сертификат на доменное имя службы B нельзя получить, не управляя доменом службы B. Сочетание этих двух пунктов и есть тело механизма сертификатов.

Порядок проверки пути сертификата задаёт RFC 5280⁵, порядок сверки имени в сертификате с именем адресата — RFC 6125⁶.

Четыре пункта действуют не с равной силой

Здесь отделим ответ экзамена от реального поведения браузера. Четыре пункта выше — то, что рис. 2 условия приводит как «подробности ошибки, которые могут отобразиться»; не читайте это как «любой браузер проверяет все четыре с одинаковой надёжностью».

Издатель, имя сервера и срок — три пункта, которые в момент получения сертификата решаются только по сведениям под рукой, поэтому проверяются всегда. Именно эти три останавливают атаку этой задачи.

Проверка отзыва по природе другая. Отозван ли сертификат, в самом сертификате не написано; нужно идти за другими сведениями, поэтому это зависит от реализации и настройки.

• Chrome обычно не делает онлайн-проверку OCSP или CRL. Вместо этого распространяет ограниченный список CRLSet, главная цель которого — быстро блокировать сертификат в чрезвычайной ситуации; из списков отзыва УЦ в каждую редакцию попадает только часть⁷
• Даже в реализациях, которые запрашивают OCSP, широко используется конфигурация soft-fail: если ответа нет, соединение пропускают

Поэтому не ставьте «если ключ унёсся — отзовём» столпом мер. Отзыв — то, что нужно делать, но это не механизм, который гарантированно действует во всех браузерах пользователей. Сокращение срока сертификатов в последние годы — и ответ отрасли на то, что на отзыв нельзя положиться. Когда в своей компании подозревают утечку ключа, параллельно с заявкой на отзыв нужно менять сертификат и признавать недействительным то, что этот ключ защищал (сессии, ключи API и т. п.).

Практическая ловушка — кто решает, что такое «доверенный удостоверяющий центр»

Дальше — вне текста задачи. Первый пункт таблицы выше зависит от того, чему доверяет это устройство. Список доверия держат браузер или ОС; в Windows это «Доверенные корневые центры сертификации» хранилища сертификатов.

То есть в следующих ситуациях первая проверка проходит.

• Корневой сертификат корпоративного УЦ (частного CA) роздан на рабочие ПК. Закрытый ключ этого УЦ или процедура выпуска сертификатов оказались у атакующего
• Прокси или продукт безопасности, который осматривает содержимое обмена, кладёт на устройство свой корневой сертификат, чтобы терминировать TLS. Этот продукт или его эксплуатация оказались у атакующего
• Кто-то когда-то зарегистрировал исключение «потому что ошибка сертификата» или положил самоподписанный сертификат в доверенный корень

Третье на площадках действительно часто. Один раз положили вручную, чтобы убрать ошибку сертификата внутренней системы, и оно живёт в образе, унаследованном с ПК уволившегося. Содержимое хранилища доверенных корневых центров сертификации — само заявление этого устройства о том, кому оно верит, поэтому делайте его объектом инвентаризации. Решение, что в какое хранилище класть, разобрано в практическом руководстве по хранилищу сертификатов Windows.

По второй проверке (совпадение имени сервера) практическая оговорка другая. На атаку, в которой пользователь путает доменное имя, сертификат бессилен. Если атакующий получит похожий домен вроде b-serv1ce.example.com и законный сертификат на этот домен, браузер ошибки не покажет. Сертификат гарантирует «имя сервера адресата совпадает с именем сервера в сертификате», а не «это имя сервера — тот, кого пользователь имел в виду». Последний шаг, который не полагается на взгляд пользователя, — способы вроде ключей доступа (WebAuthn), где происхождение проверяет сам аутентификатор. Подробнее — в почему ключи доступа безопасны.

5. Почему останавливает даже набор http:// — подвопрос 1(3)

Г-жа Y не сдаётся. Если в состоянии подключения к поддельной AP сотрудник в веб-браузере при вводе URL службы B по ошибке наберёт http://, сообщение об ошибке не появится?

Сомнение резонное. При соединении по HTTP сертификат сервера вообще не появляется. Поддельный сайт, кажется, сможет показать экран входа без какой-либо ошибки.

Ответ г-на S: «Всё в порядке. HSTS включён, поэтому и в этом случае появится то же сообщение об ошибке». Подвопрос 1(3) спрашивает поведение веб-браузера до момента, когда появляется это сообщение об ошибке, до 60 знаков.

Образец ответа: «Подменить доступ HTTP доступом HTTPS и обратиться. Затем получить сертификат сервера с поддельного сайта».

Что происходит внутри браузера

HSTS (HTTP Strict Transport Security) — механизм, которым сайт заголовком Strict-Transport-Security объявляет «к этому узлу впредь приходи только по HTTPS», а браузер это запоминает. Задано RFC 6797⁸.

Когда к запомненному узлу пытаются обратиться по http://, браузер действует так.

1. Схему URL с http подменяет на https. Если явно указан порт 80, преобразует в 443 (RFC 6797, п. 8.3)
2. В результате соединяется по HTTPS. DNS подкручен, поэтому адресат — поддельный сайт
3. Получает сертификат сервера с поддельного сайта
4. Проверка не проходит, ошибка та же, что в главе 4

Важно: подмена пункта 1 завершается до выхода в сеть. Открытый HTTP-запрос вообще не отправляется. Поэтому ситуации «соединились по HTTP, сертификата нет» не возникает.

«Игнорировать и идти дальше» нажать нельзя

Ещё одно свойство HSTS на практике очень велико. П. 8.4 RFC 6797 требует: если при установлении безопасного канала с узлом, для которого HSTS действует, произошла ошибка, будь то предупреждение или фатальная, соединение оборвать. И п. 12.1 описывает это поведение как “No User Recourse” (пользователю не давать обхода) и говорит, что нельзя предлагать выбор вроде «это соединение небезопасно, всё равно продолжить?».

При обычной ошибке сертификата многие браузеры на экране предупреждения дают «дополнительно», «продолжить». На практике не редкость, как пользователь, привыкший к ошибкам сертификата внутренних систем, жмёт это рефлекторно. HSTS этот рефлекс глушит. Как защита от поддельного сайта «нельзя нажать» действует даже сильнее самой проверки сертификата.

Предпосылка HSTS — первый раз не защищён

Однако у HSTS есть предпосылка. Как задаёт п. 8.1 RFC 6797, узел становится «известным HSTS-узлом», когда агент пользователя по безопасному каналу получил заголовок Strict-Transport-Security. То есть этот браузер уже однажды должен был дойти до настоящего сайта по HTTPS.

Поэтому в следующих случаях защиты нет.

• На только что выданном рабочем ПК первый доступ сразу случился под поддельной AP
• Профиль браузера пересоздали или стёрли данные просмотра, и запись HSTS тоже исчезла
• Истёк срок записи (max-age)

Эту первую дыру закрывает список предзагрузки HSTS. Если домен заранее стоит во встроенном в браузер списке, HTTPS принуждается, даже если доступа ещё не было.

Однако если рассматриваете регистрацию своего сайта, сначала проверьте условия. Требования регистрации такие⁹.

• Предоставлять действительный сертификат
• Если слушает порт 80, перенаправлять HTTP на HTTPS на том же узле
• Все поддомены предоставлять по HTTPS (включая www, если есть запись DNS)
• На базовом домене возвращать заголовок Strict-Transport-Security с max-age не менее 31 536 000 секунд (1 год), includeSubDomains и preload

Срабатывают третий пункт и сочетание с includeSubDomains. Если старый внутренний поддомен только на HTTP или без сертификата, в момент регистрации до него станет нельзя дойти. Перед регистрацией инвентаризируйте все поддомены.

И отмена не проста. Заявку на удаление как правило принимают, но пока изменение дойдёт до браузеров пользователей, проходят месяцы, а по браузерам кроме Chrome гарантии нет⁹. К предзагрузке безопаснее подходить как к настройке, которую «ошибся — верну» нельзя.

Со стороны потребления соответствует ли облачная служба, которой пользуетесь в работе, HSTS — пункт, который стоит включить в проверку при выборе.

6. В момент, когда одобрение выхолостилось, функция общего доступа становится путём выноса — подвопрос 2(1)

Отсюда — рассмотрение выноса сотрудником.

Г-н S сначала проверяет эксплуатацию функции общего доступа к файлам. Руководитель перед одобрением действительно смотрит адрес получателя и файл? Ответ г-жи Y: «Есть руководители, которые, кажется, не проверяют».

Тогда г-н S указывает на подвопрос 2(1). Конкретно, до 40 знаков, способ злоупотребления функцией общего доступа к файлам, чтобы скачать файл извне компании M.

Образец ответа: «В адресе внешнего получателя указать свой личный адрес электронной почты».

Дизайн верен, эксплуатация дырява

Функция общего доступа службы B сделана продуманно.

• Для общего доступа нужно одобрение руководителя
• Внешнюю ссылку не сообщают ни заявителю, ни руководителю. Заявитель не может переслать ссылку и унести
• Ссылка содержит трудно угадываемую случайную строку, срок — 1 день

Особенно второе — дизайн с оглядкой на вынос изнутри. И всё равно ломается. Если адресат — вы сами, ссылка, которая «заявителю не сообщается», приходит вам в руки.

И условие, при котором эта дыра открывается, одно: «руководитель не проверяет адресата». Поток одобрения спроектирован в расчёте, что одобряющий смотрит содержимое. Если не смотрит, это просто автоматизированный путь доставки.

Условия, при которых одобрение выхолащивается, известны

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

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

Общую картину, с чего малому и среднему бизнесу начинать, разбираем в как пользоваться 4-й редакцией «Руководства IPA по информационной безопасности для МСБ».

7. Переговорная как дыра — подвопрос 2(2)

Следующий вопрос г-на S: «В переговорную лично принадлежащий ПК принести можно?» Ответ г-жи Y: «Принос в переговорную не запрещён, поэтому можно».

Здесь появляются метод 1 и метод 2. Оба — сюжет скачать файлы из службы B на лично принадлежащий ПК и унести сам этот ПК. Настройки ПО защиты от утечек на рабочем ПК на лично принадлежащий ПК не действуют никак.

Метод 1 — подделка MAC-адреса

Метод 1: сменить [e] MAC-адрес беспроводного интерфейса лично принадлежащего ПК на MAC-адрес беспроводного интерфейса рабочего ПК и подключить лично принадлежащий ПК к беспроводной сети сотрудников. Пропуск e — ответ подвопроса 2(2).

Вход в беспроводную сеть сотрудников держали два: предварительно общий ключ WPA2-PSK и фильтрация MAC-адресов. Оба сотрудник преодолевает.

• Предварительно общий ключ задан на рабочем ПК, сотрудник — пользователь рабочего ПК. Раз все делят один ключ, исходная предпосылка — «пользователь может знать»
• MAC-адрес на стороне устройства переписывается. Обычно это настройка ОС или свойство драйвера, особых инструментов не нужно. Плюс MAC-адрес в кадрах беспроводной сети не шифруется, поэтому, приняв радио рядом, можно узнать MAC зарегистрированного рабочего ПК

Фильтрация MAC-адресов и скрытие SSID имеют смысл как наведение порядка, уменьшающее неверные подключения. Но это не механизм аутентификации, который останавливает того, кто входит намеренно. Проверьте и в своей конфигурации, не считаете ли вы эти два «мерами» в общем числе.

Метод 2 — просто подключиться к гостевой беспроводной сети

Метод 2 ещё проще. Подключить лично принадлежащий ПК к гостевой беспроводной сети, скачать файлы из службы B и унести сам ПК. Всё.

Подделка MAC не нужна. Нужен только предварительно общий ключ гостевой беспроводной сети, а его раздают гостям. Сотрудник не знать его не может.

Здесь естественно возникает следующий вопрос. Служба B же была ограничена «идентификатором, выделенным сотруднику компании M, войти можно только с глобального IP-адреса компании M»?

Что на деле разрешает ограничение по исходному IP

Читая настройки брандмауэра в тексте задачи, ответ есть. И обмен из гостевой беспроводной сети в интернет, и обмен из беспроводной сети сотрудников тем же NAT преобразуются в один и тот же глобальный IP-адрес.

Со стороны службы B эти три неразличимы. Ограничение по IP проходит насквозь.

Эта схема повторяется и вне экзамена. Ограничение по исходному IP не значит «только с этого устройства». Оно значит «от всех, кто выходит с этим глобальным IP». Типичные случаи, когда задуманная разрешённая область и реально разрешённая расходятся:

Это не речь о том, что ограничение по исходному IP бессмысленно. Речь о том, чтобы не пользоваться ограничением в один слой. Только наложив на сужение по IP механизм, который идентифицирует само устройство (клиентский или сертификат устройства), и механизм, который идентифицирует пользователя (многофакторная аутентификация), можно выразить «этот человек на этом устройстве». Меры этой задачи идут именно в эту сторону.

8. Привязать устройство сертификатом — подвопросы 3(1)–(4)

Как меру против метода 1 компания M выбирает для аутентификации беспроводной сети сотрудников EAP-TLS и готовит сервер аутентификации.

Подвопрос 3(1) — RADIUS

Подвопрос 3(1) спрашивает протокол поверх UDP, который сервер аутентификации использует для EAP. Образец ответа — RADIUS.

Схема: действующих лиц трое.

Между рабочим ПК и AP — IEEE 802.1X (EAP over LAN), между AP и сервером аутентификации — RADIUS. RADIUS работает поверх UDP¹⁰. Сам порядок EAP-TLS задаёт RFC 5216¹¹. На Windows Server роль сервера аутентификации несёт сетевой сервер политик (NPS)¹².

Зафиксируем, что меняется при переходе с WPA2-PSK на EAP-TLS.

Последняя строка нуждается в дополнении. В EAP-TLS клиент проверяет сертификат не AP, а сервера аутентификации. AP — лишь аутентификатор, который ретранслирует обмен EAP; клиент не подтверждает личность самой AP.

И всё же это готовит к evil twin главы 4, потому что ключевой материал, порождаемый только после успешной аутентификации, попадает только настоящей AP, у которой есть общий секрет RADIUS. AP, которую атакующий поднял сам, пока за ней нет настоящего сервера аутентификации, эту процедуру до конца не проведёт. Клиент напрямую проверяет сервер аутентификации, а законность AP выводится оттуда косвенно — такая структура.

Однако условно. Если на стороне клиента не задать, «сертификату сервера какого УЦ и с каким именем верить», отличить сервер аутентификации, который атакующий подготовил сам, нельзя. Конфигурация «EAP-TLS поставили, а в профиле клиента проверку сертификата сервера выключили» на практике бывает. После внедрения проверяйте и это.

Подвопрос 3(2) — неверный ответ, на который указал комментарий к оцениванию

Объяснение г-жи Y продолжается так. Клиентские сертификаты выпускает вновь создаваемый сервер УЦ; сотрудник не устанавливает их на свой рабочий ПК сам, а функция сервера каталога кладёт их на рабочий ПК. И [f], соответствующий клиентскому сертификату, хранят и защищают в TPM рабочего ПК, чтобы [g].

Подвопрос 3(2) спрашивает пропуск f. Образец ответа — закрытый ключ.

Комментарий к оцениванию пишет так.

Подвопрос 3(2) дал несколько повышенную долю верных ответов, но в части ответов встречались «открытый ключ» и «сертификат сервера». PKI — важная технология, лежащая в основе самых разных технологий безопасности, поэтому нужно хорошо понимать, в каких ситуациях и как она используется.

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

Что меняется, если положить в TPM — подвопрос 3(3)

Подвопрос 3(3) спрашивает пропуск g до 20 знаков. Образец ответа: «чтобы нельзя было вынести с рабочего ПК».

Если закрытый ключ лежит на устройстве файлом, это копируемые данные. Скопировали на лично принадлежащий ПК — и тот ПК проходит аутентификацию как рабочий. Думали, закрыли метод 1 (подделку MAC), а он просто сменяется «подделкой сертификата».

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

На Windows в поставщике хранения ключей (KSP) шаблона сертификата указывают Microsoft Platform Crypto Provider. Этот поставщик защищает ключ через TPM; если в шаблоне сертификата стоит «разрешить экспорт закрытого ключа», выбрать его нельзя¹³. Очевидное ограничение: если экспортировать можно, защищать незачем.

Саму роль детали TPM в контексте шифрования диска разбираем в практическом руководстве по BitLocker. Мышление «закрытый ключ с устройства не выпускать» — то же, что устройство аутентификатора, объяснённое в почему ключи доступа безопасны.

Почему можно сказать «проблем нет» — подвопрос 3(4)

Выслушав объяснение г-жи Y, г-н S отвечает: «При таком способе хранения, думаю, проблем нет». Подвопрос 3(4) спрашивает причину до 40 знаков.

Образец ответа: «Потому что учётные данные, нужные для EAP-TLS, можно хранить только на рабочем ПК».

Поток такой.

1. Клиентский сертификат сотрудник сам не устанавливает — функция сервера каталога раздаёт его на рабочий ПК. Через руки сотрудника не проходит
2. Закрытый ключ внутри TPM, с рабочего ПК не вынести
3. Следовательно, к беспроводной сети сотрудников по EAP-TLS может подключиться только рабочий ПК, который выдала компания
4. Лично принадлежащий ПК, даже подделав MAC, аутентификацию не пройдёт. Метод 1 закрыт

Обратите внимание на условность «при таком способе хранения». Если бы закрытый ключ лежал на рабочем ПК файлом, г-н S «проблем нет» не сказал бы. Даже при одной и той же «аутентификации клиентским сертификатом» защищаемый объём меняется от того, куда кладут закрытый ключ.

Чего TPM не защищает

С другой стороны, «положили в TPM — можно быть спокойным» — нет. TPM гарантирует только «этот ключ не скопируют на другое устройство». Следующего он не защищает.

• Если унесли само устройство. Унесли рабочий ПК — унесли вместе с TPM. По правилам компании M вынос рабочего ПК за пределы компании запрещён, но правило и техническое принуждение — разные вещи. Отдельно нужны шифрование диска (включая аутентификацию до загрузки) и эксплуатация отзыва сертификата при утрате
• Выдача себя за пользователя. TPM идентифицирует устройство, но не гарантирует, кто этим устройством управляет. Аутентификация пользователя нужна отдельно
• Вредонос, работающий на устройстве. Закрытый ключ прочитать нельзя, но код, работающий на этом устройстве, может «попросить TPM подписать». Копирование ключа предотвращено, злоупотребление, пока устройство захвачено, — нет

9. Развести исходящие IP — подвопрос 3(5)

Как меру против метода 2 (просто подключиться к гостевой беспроводной сети) компания M рассматривает два варианта. Изменить настройку NAT брандмауэра и воспользоваться службой беспроводной сети (служба D).

Подвопрос 3(5) спрашивает содержание первого изменения до 70 знаков. Образец ответа по смыслу: «Исходный IP-адрес при доступе в интернет из гостевой беспроводной сети сделать IP-адресом, отличным от сейчас используемого глобального IP» (в тексте задачи этот глобальный IP обозначен a1.b1.c1.d1).

Как видно из главы 7, метод 2 складывается потому, что обмен гостевой беспроводной сети выходит с тем же глобальным IP, что и у сотрудников. Тогда достаточно преобразовывать только гостевую беспроводную сеть в другой глобальный IP. Ограничение по IP на стороне службы B не меняют, а доступ из гостевой беспроводной сети из него выпадает.

Это складывается потому, что на стороне WAN компании M выделено несколько глобальных IP-адресов. Читая настройки интерфейса брандмауэра в тексте задачи, маска подсети на стороне WAN — 255.255.255.248, то есть /29, и доступных адресов не один. Скромная, но надёжная заготовка, которая заставляет внимательно читать таблицы условия.

Можно ли тот же ход в своей компании, зависит от того, даёт ли контракт на линию несколько глобальных IP. Если один — этот вариант не взять. Тогда вариант отделения следующей главы.

10. Мера до удаления ставших ненужными настроек — подвопросы 3(6)(7)

В итоге компания M решает воспользоваться службой D.

• В переговорной ставят беспроводной маршрутизатор (маршрутизатор D), выданный службой D
• На маршрутизаторе D включают функции сервера DHCP и кэш-сервера DNS
• Принесённые гостем устройства не идут через сеть компании M, а выходят в интернет через SIM, встроенную в маршрутизатор D
• Проектор без гостевой беспроводной сети переводят на подключение кабелем HDMI

flowchart LR
    accTitle: После мер гостевую сеть отделяют
    accDescr: Сеть сотрудников — EAP-TLS и TPM; принесённые гостем устройства выходят в интернет через SIM маршрутизатора D, не проходя сеть компании M
    subgraph M["Внутренняя сеть компании M (после мер)"]
        direction TB
        E["Беспроводная сеть сотрудников<br/>EAP-TLS + RADIUS<br/>закрытый ключ внутри TPM"]
        S["Сеть серверов"]
        FW["Брандмауэр"]
        E --> FW
        S --> FW
    end
    subgraph K["Переговорная"]
        T["Принесённое гостем устройство"]
        D["Маршрутизатор D<br/>напрямую в интернет через SIM"]
        T --> D
    end
    FW --> B["Служба B"]
    D --> I["Интернет"]

Рис. 3: Гостевая сеть физически и логически отделена от сети компании M; с тем же глобальным IP она больше не выходит.

Гостевая сеть физически и логически отделена от сети компании M. С тем же глобальным IP она больше не выходит.

Подвопрос 3(6) — обмен, который становится ненужным

Когда принесённые гостем устройства перестают пользоваться сетью компании M, становятся ненужными обмен с сервером DHCP и сервером [h], которые были нужны до сих пор. Образец ответа пропуска h — DNS.

У самого маршрутизатора D есть функции сервера DHCP и кэш-сервера DNS, поэтому принесённым гостем устройствам не нужно пользоваться серверами DHCP и DNS в сети серверов компании M. Перечитав объяснение в тексте задачи, это написано как есть.

Подвопрос 3(7) — перечислить все настройки, которые нужно удалить

Подвопрос 3(7) просит перечислить все номера пунктов настроек интерфейса VLAN и фильтрации брандмауэра, которые нужно удалить в связи с этим изменением.

Ответ: из настроек интерфейса VLAN — VLAN гостевой беспроводной сети (пункт 1); из настроек фильтрации — два: правило, разрешающее HTTP/HTTPS из гостевой беспроводной сети в интернет (пункт 1), и правило, разрешающее доступ из гостевой беспроводной сети к DNS сети серверов (пункт 4). Плюс из настроек AP удаляют настройку гостевого SSID.

Комментарий к оцениванию пишет так.

Подвопрос 3(7) дал высокую долю верных ответов. Нужно было понять влияние пересмотра всех настроек фильтрации брандмауэра и среды беспроводной сети и ответить соответственно; понято было надлежащим образом.

Подвопрос с высокой долей верных ответов, но на практике до этого доводят немногие организации. На работу «вставить новый механизм» дают и бюджет, и срок; на работу «удалить старые настройки» — нет. И забытое удаление потом выходит наружу так.

Брандмауэр этой задачи оценивает правила сверху вниз по номеру пункта и применяет первое совпавшее (в тексте задачи это прямо сказано). При таком способе оставить ставшее ненужным правило разрешения выше — то же, что держать дыру, чтобы не дойти до отказа в хвосте.

Однако этот способ оценки не обобщайте на все брандмауэры. У продуктов способ разный.

При любом способе оставлять неиспользуемое разрешение опасно само по себе не меняется. Меняются «почему опасно» и «как чинить». Подтвердив, какой способ у своего оборудования, в регулярную инвентаризацию включайте пункт «источник и назначение всё ещё существуют».

Как на стороне бизнес-приложения управлять нужными входящими правилами — разговор о хостовом брандмауэре — в брандмауэре Windows и бизнес-приложениях.

11. Меры, которые не сработали, и меры, которые сработали

Свести эту задачу на один лист — следующая таблица. Соответствие мер, которые были у компании M, и путей, которыми их обошли.

Только последняя строка — «сработало». И меры, которые спроектировали, выглядят так.

Сравнив, разница характера ясна. Обойденные меры часто запрещают «средство», а сработавшие и спроектированные меняют «путь» или «природу учётных данных». Закроете USB — вынос сложится, пока путь к файлам остаётся; удлините предварительно общий ключ — общей тайной он быть не перестанет.

12. Контрольные точки практики

Пункты проверки, когда эту задачу накладывают на свою конфигурацию.

1. Можно ли выписать меры против выноса путями, а не средствами. Не список средств USB / вложение в почту / веб-почта, а «список устройств и сетей, которые могут дойти до рабочих файлов». Если есть хотя бы один путь, которым доходит неуправляемое устройство, запрет средств обходят
2. Не ограничивают ли правила приноса и выноса местом. «Запрет приноса в рабочие помещения» разрешает переговорную, приёмную, общие пространства. Совпадают ли физические зоны и зоны сети
3. Можно ли сказать, какую область на деле разрешает ограничение по исходному IP. Пересчитать всё, что выходит с этим глобальным IP. Гостевой Wi-Fi, гостевая сеть, VPN между площадками, агрегатный шлюз удалённой работы, среда проверки
4. Стали ли учётные данные беспроводной сети поустройствами. Предварительно общий ключ — общая тайна, которую все держат одинаково: утечёт у одного — утекли у всех, остановить только одну машину нельзя
5. Не кладут ли фильтрацию MAC и скрытие SSID в число мер. И то, и другое — наведение порядка, уменьшающее неверные подключения, а не аутентификация
6. Нельзя ли вынести закрытый ключ клиентского сертификата с устройства. Закрытый ключ, лежащий файлом, копируется. Указать поставщик хранения ключей, использующий TPM, и не разрешать экспорт
7. Проверяет ли клиент, куда поставили EAP-TLS, сертификат сервера аутентификации. Если это выключить, устойчивость к поддельному серверу аутентификации пропадает
8. Не в состоянии ли пользователь обойти ошибку сертификата сервера «продолжить». На своих сайтах задавать HSTS. Не оставлять ошибки сертификата внутренних систем и не учить пользователя, что «ошибку жмут и идут дальше»
9. Инвентаризируют ли содержимое хранилища доверенных корневых центров сертификации. То, что там лежит, — адресат, которому это устройство заявляет «сертификат, выпущенный этим УЦ, считаю настоящим»
10. Достаёт ли до одобряющего в потоке одобрения материал для решения. И смотрят ли результат одобрения потом. Регулярно списком смотреть общий доступ на внешние домены и бесплатную почту
11. Удаляют ли настройки упразднённого пути. Интерфейс VLAN, правила фильтрации, SSID, записи списка разрешения. Работе «удалить» давать тот же срок, что работе «вставить новое»

В заключение — мера, у которой не написан «объём», не защищает

Если вопрос 1 спрашивал «какую атаку на каком этапе эта мера останавливает», вопрос 2 спрашивает «какой объём эта мера защищает».

У каждой меры компании M был неявный объём. Объём ПО защиты от утечек — до рабочего ПК. Объём запрета приноса — до рабочих помещений. Объём фильтрации MAC — «до того, кто не подделывает». Объём ограничения по исходному IP — «до всех, кто выходит с этим глобальным IP». Каждый объём работал правильно — просто стык с соседом был открыт.

Практичность этой задачи в том, что компания M нарисована как компания, которая меры принимала всерьёз. После прошлогоднего происшествия закрыли оба конца пути и даже поставили специальное ПО. Дыры остаются не потому, что ответственные ленились, а потому что способ «добавлять меры по одной» не даёт увидеть щели объёма.

Чтобы найти щель, нужно писать не список мер, а список путей. Именно это делали г-жа Y и г-н S этой задачи. Разделить «внешнего атакующего» и «сотрудника» и по одному закрывать пути достижения для каждого. «Способность с разных углов предполагать угрозы в среде с беспроводной сетью», которую IPA написала в замысле вопроса, — эта работа.

Смежные области консультирования

KomuraSoft LLC занимается ревью дизайна, исходящим из существующей сети и конфигурации устройств, и реализацией раздачи сертификатов и защиты ключей в среде Windows.

• Технические консультации и ревью дизайна
• Разработка приложений для Windows
• Расследование ошибок и причин
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Запретили USB и запретили сохранение на локальный диск. Почему файлы всё равно можно унести?

Потому что запретили функцию выданного компанией рабочего ПК, а не путь к месту, где лежат файлы. В этой задаче сотрудник пользуется своим лично принадлежащим ПК. Не трогая рабочий ПК вовсе, он подключает личный ПК к беспроводной сети переговорной, входит в облачное хранилище (служба B) со своим идентификатором пользователя, скачивает файлы и уносит сам личный ПК. Настройки ПО защиты от утечек на рабочем ПК на лично принадлежащий ПК не действуют никак. Компания M запрещала принос лично принадлежащих ПК на территорию — но только в рабочие помещения; переговорная была вне запрета. Даже если средства (USB, вложения в почту, веб-почта) закрывать по одному, вынос удаётся, пока остаётся какой-то путь к файлам.

Служба B была ограничена «вход только с глобального IP-адреса компании M». Почему это не останавливает доступ с гостевой беспроводной сети?

Потому что трафик гостевой беспроводной сети тоже проходит через NAT того же брандмауэра и преобразуется в тот же глобальный IP-адрес, прежде чем выйти в интернет. Со стороны службы B доступ с рабочего ПК внутри офиса и доступ с лично принадлежащего ПК, подключённого к гостевой беспроводной сети в переговорной, выглядят одним и тем же исходным IP. Их нельзя различить. Ограничение по исходному IP-адресу нужно понимать как разрешение не «только с этого устройства», а «всем, кто делит этот выход». Гостевой Wi-Fi, VPN между площадками, агрегатные шлюзы удалённой работы — всё, что выходит с тем же глобальным IP, входит в разрешённую область.

На беспроводной сети сотрудников стояла фильтрация MAC-адресов. Разве это не мера?

Нет. MAC-адрес на стороне устройства свободно переписывается. Метод 1 в этой задаче — сменить MAC-адрес беспроводного адаптера лично принадлежащего ПК на MAC-адрес зарегистрированного рабочего ПК и подключиться. MAC-адреса в кадрах беспроводной сети летят незашифрованными, поэтому атакующий, приняв сигнал рядом, тоже может узнать зарегистрированный MAC. То же верно для скрытия SSID. Даже при выключенной рассылке SSID идентификатор сети становится ясен из обмена при подключении устройства. Фильтрация MAC-адресов и скрытый SSID уменьшают случайные неверные подключения, но это не механизм аутентификации, который останавливает того, кто подключается намеренно.

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

Потому что, пока соединение идёт по HTTPS, поддельный сайт не проходит проверку сертификата сервера. Рис. 2 условия перечисляет четыре пункта, которые могут появиться как подробности получившейся ошибки: выдан не доверенным удостоверяющим центром; имя сервера в сертификате отличается от имени сервера, к которому подключаются; отозван; истёк. Атакующий обычно не может получить законный сертификат на доменное имя службы B, поэтому самоподписанный падает на первом пункте, а сертификат, законно полученный на собственный домен атакующего, — на втором. По комментарию IPA к оцениванию доля верных ответов на вопрос об этом содержании проверки была низкой. Эти четыре пункта действуют не с равной силой. Атаку на деле останавливают первые два (издатель и имя) плюс срок — браузеры их проверяют всегда. Проверка отзыва, напротив, зависит от реализации и настройки. Chrome, например, обычно не делает онлайн-проверку OCSP или CRL, а использует ограниченный список CRLSet, главная цель которого — экстренная блокировка. Не считайте, что отзыв сертификата гарантированно его отсечёт. И если на рабочий ПК роздан корневой сертификат корпоративного УЦ, а закрытый ключ этого УЦ или процедура выпуска оказались у атакующего, первая проверка тоже проходит.

Что будет, если URL набрать как «http://»? Что на самом деле делает HSTS?

Браузер перед соединением подменяет HTTP на HTTPS, поэтому результат снова — ошибка сертификата сервера. HSTS — механизм, которым браузер запоминает содержимое заголовка, полученного в прошлый раз при HTTPS-соединении с этим сайтом. RFC 6797 требует: если в URL целевого узла есть схема http, агент пользователя заменяет её на https, а явно указанный порт 80 преобразует в 443. То есть открытый HTTP-запрос с машины не уходит. Ещё важнее: если при обмене с узлом, для которого HSTS действует, проверка сертификата не проходит, спецификация требует оборвать соединение независимо от того, предупреждение это или фатальная ошибка. Прямо сказано, что пользователю нельзя предлагать выбор вроде «это соединение небезопасно, всё равно продолжить?». Однако HSTS предполагает, что браузер уже однажды дошёл до настоящего сайта по HTTPS и получил заголовок. Он не защищает, если самый первый доступ с совершенно нового устройства сразу попадает на поддельный сайт. Эту первую дыру закрывает встроенный в браузер список предзагрузки.

Что меняется, если закрытый ключ клиентского сертификата хранить в TPM?

Закрытый ключ больше нельзя вынести с этого рабочего ПК. Закрытый ключ, лежащий файлом на устройстве, достаточно скопировать на лично принадлежащий ПК — и тот ПК пройдёт аутентификацию как рабочий. Если ключ порождён внутри TPM и задан как неэкспортируемый, операции вроде подписи происходят целиком внутри TPM, и сам ключ не доходит ни до ОС, ни до вредоноса. В результате EAP-TLS могут завершить только рабочие ПК, которые выдала компания. Поэтому г-н S мог сказать «при таком способе хранения проблем нет». Реализация на Windows — указать Microsoft Platform Crypto Provider как поставщик хранения ключей шаблона сертификата и не разрешать экспорт закрытого ключа. Имейте в виду: TPM защищает только от копирования ключа на другое устройство и ничего не делает против того, у кого это устройство физически есть. Утрату или кражу самого устройства по-прежнему нужно закрывать отдельно — шифрованием диска и отзывом сертификата.

Что из этой задачи стоит унести в свою практику?

Четыре вещи. Первое: меры против выноса думать путями, а не средствами. Закрывать USB, вложения в почту и веб-почту по одному бессмысленно, если остаётся устройство, которое всё ещё может дойти до файлов. Второе: выписать, что на деле разрешает ограничение по исходному IP. Если гостевой Wi-Fi или VPN делят тот же выход, они тоже в разрешённой области. Третье: сделать учётные данные беспроводной сети поустройствами. Предварительно общий ключ — общая тайна, которую все держат одинаково: утечёт у одного — утекли у всех. Переход на EAP-TLS с клиентскими сертификатами и ключ, который не покидает TPM, привязывает учётные данные к устройству. Четвёртое: удалять настройки, которыми больше не пользуются. Последний подвопрос этой задачи просит перечислить все оставшиеся параметры интерфейса VLAN и правила фильтрации брандмауэра после отказа от гостевой беспроводной сети — по комментарию IPA к оцениванию доля верных ответов была высокой, но на практике до этого доводят немногие организации.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.