Author Topic: Компроментация сетевого PXE-загрузчика (ключа шифрования) DiskCryptor.  (Read 2739 times)

alkoro

  • Sr. Member
  • ****
  • Posts: 418
Quote
Disclaimer:
Ниженаписанное являлось лично для меня очевидным. Однако, как оказывается, очевидное одному не всегда очевидно для всех. Поэтому ниже будут описаны действия, как демонстрация, можно назвать это proof of concept.


ИСХОДНЫЕ ДАННЫЕ:

Для испытаний я использовал три виртуальных машины.
1 - сервер DHCP и TFTP с сетевым DC-загрузчиком.
2 - зашифрованная DC рабочая станция, компьютер-жертва, который будет скомпрометирован.
3 - рабочая станция злоумышленника, с которой ведётся наблюдение за сетевой активностью.
Все три машины находятся в одной локальной сети. Адрес и маска сети 192.168.101.0/255.255.255.0

На первой машине установлена ОС Windows Server 2003 SP2, установлен и настроен стандартный DHCP-сервер c IP 192.168.101.1.

В качестве TFTP/DHCP-сервера использовалась программа TFTP32/64 (http://tftpd32.jounin.net/). Дополнительно проверялась работа стандартного DHCP-сервера от Miscrosoft.
Настройки MS DHCP и TFTP на картинке SRV1-CONF.png, дополнительная настройка tftp32 в роли DHCP-сервера на картинке SRV2-CONF.png.
В данном случае DHCP настроен таким образом, что он предоставляет загрузочные настройки исключительно для выделенного MAC-адреса шифрованной машины. Из опций (PCXX Properties) главными в нашем случае являются параметры 066 Boot Server Host Name и 067 Bootfile Name - IP-адрес TFTP-сервера (192.168.101.1) и имя файла-образа PXE-загрузчика (PX1NET-OPENKEY.IMG).

На второй машине установлена ОС Windows 7 x64 SP1, адрес сети назначается автоматически. Конфигурация жёсткого диска, настройки PXE-загрузчика DiskCryptor на картинке VICTIM1-CONF.png, дополнительные настройки загрузчика на картинке VICTIM2-CONF.png.
Оба раздела жёсткого диска зашифрованы одинаковым пустым паролем с одинаковым ключевым файлом. В BIOS Setup установлена загрузка через сетевой интерфейс.
Опции PXE-загрузчика указывают на беспарольный старт с использованием встроенного ключевого файла. Ключевой файл представлен в виде явной символьной строки [THIS IS SECRET NETWORK KEYFILE, PLAIN TEXT, UNSECURED DATAFILE] только для удобства и наглядности.
На картинке VICTIM-PXE-START.png сам момент старта ОС, видны сообщения от PXE-модуля BIOS.

На третьей машине установлена ОС Windows Server 2003, установлен сетевой анализатор WireShark (https://www.wireshark.org/). С его помощью собирались пакеты, проходящие в сети в момент старта второй рабочей станции.

ПРОВЕДЕНИЕ АТАКИ:
Так как в опыте использовалась виртуальная среда, то Wireshark мог собирать все пакеты, идущие между компьютером-жертвой и сервером, в реальности это конечно же не так, и анализатор может увидеть только пакеты, адресованные непосредственно атакующему узлу, либо широковещательные пакеты. Но, как оказалось, и таких данных вполне достаточно для успешного проведения атаки.

Для удобства сначала рассмотрим "тепличный" вариант с полным дампом пакетов, чтобы наглядно увидеть, что и когда передаётся в сети. В нашем случае это достигается переключением режима сетевого адаптера в настройках Wireshark в Promiscuous mode.

На картинке WIRE-PROMIS-GENERAL.png представлена общая последовательность пакетов для случая использования штатного DHCP (Microsoft) и TFTP32 на "сервере".
Пояснения:
Пакеты 1 - 6  - получение сетевых настроек компьютером-жертвой от DHCP-сервера.
Пакеты 7 - 88 - TFTP-сессия, передача файла, загрузчика DC PXE-клиенту, непосредственная передача тела файла это пакеты 11-88, чередующиеся блоками данных от сервера к клиенту и ответами-подстверждениями приема от клиента к серверу.
Пакеты 90 и далее - это сетевая активность уже загруженной ОС Windows 7.
пакеты 90 и 91 - повторный DHCP-запрос от ОС, видна характерная временнАя задержка между 89 и 90 пакетами, необходимая для загрузки ОС.

На картинке WIRE-PASSIVE-GENERAL.png представлена та же последовательность пакетов для того же случая, именно такую картину будет наблюдать гипотетический злоумышленник, если подключится к локальной сети с целью слежки. Здесь видны только широковещательные пакеты:
Пакеты 1 - 5 - PXE-загрузка
Пакеты 6 и далее - загрузка и работа ОС.

Собственно, для успешного проведения атаки необходимо получить PXE-загрузчик и узнать IP-адрес TFTP-сервера. Ключевой файл извлекается из тела загрузчика, он
имеет длину 64 байта, и находится по смещению 0326eh от начала файла для данной версии DC (1.1.846.118).
Дополнительно может потребоваться MAC-адрес сетевой карты жертвы, это может понадобиться только для корректной эмуляции сетевого интерфейса компьютера-жертвы с целью
обеспечения доступа к TFTP-серверу, но, обычно как таковые, TFTP-серверы не имеют такой защиты.

На картинке WIRE-DHCP-OFFER.png показано, где извлекаются все интересующие данные:
Пакет 2, предложение DHCP, выданный сервисом клиенту, в котором всё и находится:
Your (client) IP address: 192.168.101.10 - предложенный IP-адрес клиента.
Next server IP address : 192.168.101.1 - это параметр означает IP-адрес TFTP-сервера, он же параметр 066 Boot Server Host Name.
Client MAC address: vmware_e0:e0:48 (00:0c:29:e0:e0:48) - МАС адрес клиента, его же видно и в других местах сохранённой сессии.
Bootfile name = "PX1NET-OPENKEY.IMG" - имя файла-образа PXE-загрузчика, хранимого на TFTP-сервере, он же параметр 067 Bootfile Name.
В локальной сети могут быть несколько DHCP-серверов, поэтому необходимо рассматривать все пакеты типа DHCP Offer от разных DHCP-серверов и принимать во внимание такой, на который есть ответ от DHCP-сервера DHCP ACK (пакет номер 4) - именно это предварительное предложение будет принято клиентом.
Также можно принимать во внимание пакеты 5 и 6 - ARP-пакеты. По расшифровке 5-го видно, что клиент получил адрес 192.168.101.10 (и все предложенные настройки) от DHCP сервера с адресом 192.168.101.1.

Ещё картинка WIRE-TFTP-KEY.png:
здесь показано, где именно находится ключевой файл в передаваемом загрузчике (TFTP-сессии). Diskcryptor "повезло", ключевой файл не разрывается пакетами, лежит целиком внутри одного из пакетов. Повторюсь, это идеальный академический случай, в реальности такая передача может быть перехвачена, только если локальная сеть реализована на некоммутируемых устройствах, которые уже наверное, сейчас не производят и не используют.

Итак, после получения первичных данных, злоумышленник может сразу же попытаться получить загрузчик, используя эти знания. Обычно TFTP-серверы не защищены от доступа
по IP-адресу.

На картинке TFTP-IMAGE-KEY.png представлен процесс получения. Я использовал встроенный TFTP клиент, для Windows 7,8,10 он добавляется через панель управления (Добавление компонентов Windows).
Команда получения в нашем случае tftp.exe -i 192.168.101.1 GET PX1NET-OPENKEY.IMG
После получения можно ознакомиться и извлечь ключевой файл по известному смещению. Смещение, если оно будет неизвестно (например иная версия загрузчика), то оно вычисляется:
после ключевой последовательности идут сообщения об ошибках загрузчика (partition unbootable, I/O Error и т.д), а начало ключа предваряется нулевыми байтами.

Это был первый вариант атаки, когда рабочая станция злоумышленника устанавливается на дежурство, производится сбор и анализ сетевых пакетов, которые нужно фильтровать на характерные признаки (DHCP Discover/DCHP Offer).

Второй вариант, вытекает из знаний, полученных на первом примере:
Для проведения успешной атаки нужно знание MAC-адреса зашифрованного компьютера, нет необходимости ожидания её реального старта. Иногда МАС-адрес печатается на материнской плате или наклейках, но мы рассматриваем реальный случай, когда дополнительных сведений может не быть. Технически это достигается подключением компьютера-жертвы в контролируемую злоумышленником сеть с подставным DHCP-сервером. По лог-файлам DHCP-сервера получается сетевой MAC адрес. Этот MAC-адрес включается в настройки сетевой карты контролируемой подставной рабочей станции. Идеальный вариант - это компьютер с сетевым анализатором и установленной виртуальной машиной, в которой можно легко изменить MAC адрес. По записанным логам анализатора получаем реальные данные из ответов настоящего DHCP-сервера, и дальше с подставной рабочей станции скачивается и  извлекается загрузчик.

ИТОГИ:

Лишь некоторые методы помогут частично снизить вероятность взлома, но не исключат польностью, как то:
- Настройка DHCP-сервера таким образом, чтобы сетевые настройки, необходимые для запуска шифрованной станции выдавались исключительно по MAC-адресу запросившей. Это можно отнести о обязательному действию, потому что если так не сделать, то злоумышленнику практически не нужны никакие ухищрения - просто делается запрос загрузки с любого компьютера - любая рабочая станция получит идентичные установочные данные.
В программе tftp32, где есть возможность использования встроенного DHCP-сервера, как раз нет выделенных настроек для конкретной пары MAC-IP, единственное, что там есть - это назначение конкретному MAC статического IP.
- Включение TFTP-сервера (или предоставление доступа к загрузчикам) только на определенное время, в идеале - по запросу пользователя (аутентификации пользователя с помощью какого-либо дополнительного программно-аппаратного решения).
- Так как TFTP-сервер не имеет встроенных средств защиты, то обеспечение этой защиты от несанкционированного доступа на программном уровне путем разграничения доступа с помощью брандмауера ("белый список" IP, MAC) и на транспортном уровне, то есть, например, с помощью управляемых свитчей предоставлять доступ к порту, к которому подключен TFTP-сервер, только портам, к которым подключены шифрованные рабочие станции. Недостаток - нужно дорогое дополнительное оборудование и ПО, и увеличение вероятности похищения ключа с ростом числа шифрованных рабочих станций. Опять-таки, не исключена ситуация использования именно того самого выделенного для данной рабочей станции порта злоумышленником.

В любом из вариантов, итог будет однозначно одинаковым: загрузка шифрованных рабочих станций по сети с аутентификацией ТОЛЬКО по ключевому файлу - это совсем никак не безопасно.

Простое добавление аутентификации по ключу И ПАРОЛЮ сводит на нет описанные выше действия, в любом случае это серьёзно затруднит или отсрочит компроментацию.

ВЫВОД:
Автоматическая аутентификация без участия человека обречена на провал и компроментацию. И наоборот, введение человеческого контроля затрудняет доступ.

В прикрепленных файлах есть архив со всем, имеющим отношение к тексту - файлы загрузчика, ключевой файл, записанные сетевые сессии и иллюстрации.
« Last Edit: December 11, 2015, 11:50:43 am by alkoro »

alkoro

  • Sr. Member
  • ****
  • Posts: 418
Иллюстрации - продолжение

alkoro

  • Sr. Member
  • ****
  • Posts: 418
Иллюстрации - окончание
« Last Edit: December 11, 2015, 11:16:21 am by alkoro »