История использования USB

Метки:  , , ,

Ни для кого уже не секрет, что информация о разного рода активности многочисленных компонентов операционной системы попадает в реестр и файлы в виде записей заданного формата. При этом, информация эта нередко содержит чувствительные пользовательские данные: историю посещенных браузером страниц, кеш данных программ, информацию о подключаемых устройствах и многое многое другое. Во основном журналирование обеспечивается функциональными особенностями пользовательских программ, которые имеют встроенные алгоритмы сохранения истории операций, отчасти это возможно благодаря архитектурным особенностям ядра/HAL операционной системы, которые, производя конфигурирационные действия с устройствами, сохраняют информацию о последних в виде записей в системном реестре. Из всего многообразия подобной информации, в рамках данной статьи нас будет интересовать исключительно история использования USB устройств.

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

Система создает артефакты в момент обнаружения (инициализации) устройства (сменных накопителей, модемов, гаджетов, камер, медиаплееров и прч.) на шине компьютера. Дополнительным плюсом данного материала будет возможность сбора доказательной базы по факту неправомерного использования рабочей станции пользователя в корпоративной среде при помощи незадекларированных USB-устройств.

Не так давно в нашу жизнь вошел интерфейс USB, привнеся в неё довольно существенные изменения. Неожиданно многие вещи стали проще, отпала необходимость инсталляции устройства во внутренний интерфейсный разъем (шина), или внешний интерфейс, требующий перезагрузки станции для корректной инициализации устройства, да и сам процесс конфигурирования устройств стал, во множестве случаев, тривиальнее. На интерфейсе USB появились тысячи разнообразных по назначению устройств, которые достаточно было подключить к разъему на панели корпуса, после чего от момента подключения до состояния "готов к работе", порой проходили считанные минуты. Наряду с очевидными достоинствами: легкостью конфигурирования/использования, компактностью, функциональностью, подобные устройства сразу стали источником проблем как для безопасности персональных данных самого пользователя, так и безопасности корпоративных сред. Компактный, легко маскируемый "брелок" с интерфейсом USB может запросто явиться той ахиллесовой пятой, которая станет причиной "падения" гиганта корпоративной безопасности. Если порты USB в корпоративных рабочих станциях находятся без надлежащего контроля со стороны политик безопасности, то любое приспособление может запросто выступить в качестве средства для обхода периметра безопасности компании. И тут уж насколько хватит фантазии "взломщика", например, достаточно пронести на флешке свежий, не определяемый антивирусами вредоносный код и выполнить его (умышленно или нет), и вот вам уже прецедент, поскольку даже без локальных административных привилегий учетной записи пользователя сохраняется пространство для маневра. Не меньшую опасность представляют и USB-модемы, которые, в случае установки (а при использовании локальных/доменных политик по умолчанию это достигается достаточно просто), могут выступить в роли неконтролируемого канала передачи данных, по которому может осуществляться передача чувствительной корпоративной информации за пределы защищенного внутреннего периметра. При этом, даже декларируемые (заявленные/согласованные) пользовательские устройства (например, телефоны) могут содержать в своих микропрограммах или операционных системах уязвимости, которые, в случае эксплуатации, наносят вред не только владельцу, но и могут выступать в роли средства несанкционированного доступа к служебным данным. Поэтому, в случае возникновения инцидента информационной безопасности, связанного с эксплуатацией USB-устройств,

все действия с USB-устройствами могут рассматриваться как доказательная база при возникновении преступления в сфере информационной безопасности.

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

Нумерование (энумерация) USB устройств

Поскольку я сам в данном вопросе "плаваю", перед тем как перейти к практике, предлагаю немного усилить нашу теоретическую базу и описать терминологию, которая будет использоваться на протяжении всего материала. Сразу оговорюсь, что мы не будем освещать все виды взаимодействия, выполняющиеся на шине USB на аппаратном уровне, а сосредоточимся исключительно на основных понятиях, относящихся к USB-устройствам и требующихся нам для понимания практической стороны вопроса.
Подключение любого нового оборудования сопряжено с выполнением модулями ядра системы Windows предопределенных фаз опроса и инициализации. Начинается всё с того, что при подключении устройства к разъему USB, контроллером USB (встроенным в чипсет на материнской плате) генерируется аппаратное прерывание. Драйвер USB, ответственный за обработку данного прерывания, запрашивает статус порта, и если статус указывает на подключенное устройство, то ответственными подсистемами ядра производится последовательность действий, которую условно можно разделить на две стадии:

  1. Нумерование устройства;
  2. Установка драйвера устройства;

Ядро (?) инициирует к вновь подключенному устройству серию запросов GET_DESCRIPTOR с различными типами запрашиваемых дескрипторов (Device, Configuration, LangID, iProduct). Запросы опрашивают устройство на предмет наличия серии дескрипторов, представляющих собой структуры данных, описывающие возможности USB устройства.

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

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

Название поля Терминология Windows Размер (байт) Комментарий
idVendor VID 2 Идентификатор производителя устройства. При присвоении идентификатора производителя, соответствующее числовое значение вносится в реестр производителей.
idProduct PID 2 Идентификатор продукта. Назначается производителем устройства. Product ID используется для дифференциации продуктов в рамках одного производителя.
bcdDevice REV 2 Идентификатор ревизии. Используется для дифференциации разных аппаратных модификаций в рамках одной модели устройства. Может использоваться при выпуске новой версии платы/контроллера/логики.
bDeviceClass, bFunctionClass, bInterfaceClass Class 1 Класс устройства. Используется для задания класса схожих устройств с общим набором идентичных свойств.
bDeviceSubclass, bFunctionSubClass, bInterfaceSubclass SubClass (SUB) 1 Подкласс устройства. Используется для задания подкласса схожих устройств в рамках класса.
bDeviceProtocol, bFunctionProtocol, bInterfaceProtocol Protocol (Prot, PROTO) 1 Протокол устройства. Используется для задания протокола для устройств в рамках класса и подкласса.
iProduct Product ? Текстовая строка-описатель продукта. Когда устройство подключено к компьютеру, данная информация отображается в Диспетчере устройств.
iSerialNumber Serial ? Серийный номер. Используется для уникализации абсолютно одинаковых устройств, например две одинаковых флешки. Назначается и поддерживается производителем устройства. Связанный механизм носит имя Сериализация. Сериализация так же участвует в уникальной идентификации устройства, поскольку добавляет еще один уровень уникальности.

Наверняка многие из перечисленных в таблице полей Вам уже встречались в составе значений различных параметров в том же Диспетчере устройств либо в разнообразных системных лог-файлах.
Помимо стандартных дескрипторов, существуют еще так называемые Дескрипторы Microsoft (Microsoft OS Descriptors, MOD), которые содержат специфичную для ОС Windows информацию. Для поддержки производителей, чьи устройства из-за функциональных особенностей не подходят под стандартный набор классов, Майкрософт разработала набор специальных классов и собственных дескрипторов. Пользовательское и системное ПО может идентифицировать устройства, принадлежащие к разработанным Майкрософт классам устройств путем опроса устройства на предмет наличия дескрипторов Microsoft. Помимо поддержки описанных классов устройств, дескрипторы Microsoft имеют и иное применение, например при помощи них можно использовать память устройства для хранения файлов помощи, иконок, списков адресов URL, настроек системного реестра и других данных, используемых для обеспечения прозрачности установки и достижения смежных целей. Устройства, поддерживающие дескрипторы Microsoft, должны хранить специальный строковый дескриптор в прошивке с фиксированным индексом 0xEE. Операционные системы Windows XP SP1 и более поздние запрашивают этот строковый дескриптор у устройства при первом его подключении.

Таким образом, каждое USB устройство должно иметь, как минимум: идентификатор производителя (VID, Vendor ID), идентификатор продукта (PID, Product ID), и серийный номер (Serial). На основе этих параметров формируется уникальный идентификатор оборудования, тем самым обеспечивается уникализация USB-устройства в пределах системы и вносятся изменения в конфигурацию оборудования.

Более того, использование пары VID/PID в дескрипторе любого USB-устройства предписывается спецификацией, согласно которой данные параметры должны быть уникальны для каждой модели устройства. Ну это, опять же, все в теории, а на практике пару раз встречались экземпляры устройств, в которых значения VID/PID были рандомизированы, либо просто взяты свободные значения (!) из реестра. Могу предположить, кому выгодно подобным заниматься :) Ну это скорее редко встречающаяся ситуация, когда производителю хочется сэкономить деньги на внесении в реестр производителей.
Затем, после того, как у устройства запрошены ключевые параметры, для USB устройства создан уникальный идентификатор HardwareID (CompatibleID), однозначно идентифицирующий устройство/класс устройства. Драйвер USB-концентратора уведомляет специализированный модуль ядра под названием Диспетчер Plug-n-Play (PnP Manager) о новом устройстве. Диспетчер PnP получает идентификаторы HardwareID и CompatibleID устройства и пытается обнаружить устройства с аналогичными идентификаторами HardwareID/CompatibleID. В этот момент в системе создается узел устройства (devnode), что является, по сути, первым отпечатком USB устройства в системе. Если похожее устройство найдено, то производится установка соответствующих драйверов в автоматическом режиме, если же не найдено, то Диспетчер PnP получается уведомление о новом устройстве и далее действует по определенным правилам, описание которых выходит за рамки данного материала.

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

Эксперимент

В Сети много противоречивой информации относительно истории подключения USB, поэтому давайте проведем собственный эксперимент по выявлению всех возможных системных местоположений, формирующих историю USB подключений. С целью выявления следов подключения USB стоит отследить абсолютно все изменения, происходящие в системе в момент подключения USB устройства. С этой целью на просторах Сети была найдена замечательная утилита под названием SysTracer, которая обладает всем необходимым функционалом. Утилита настолько проста и функциональна, что во многих случаях она окажется незаменимым средством в руках специалиста, поскольку предоставляет возможность сделать КРАЙНЕ полезное действие: создать мгновенный снимок (snapshot) состояния ключевых компонентов системы, таких как реестр и файлы. В качестве системы я использовал чистую инсталляцию Windows 7 Professional, при этом главным требованием было отсутствие каких-либо подключений внешних носителей. Итак, делаем снимок чистой системы, затем вставляем тестовую USB-флешку SanDisk Cruzer mini 1.0Gb и через некоторое время делаем второй снимок. Встроенными средствами утилиты SysTracer сравниваем полученные образы с выводом отчета. В итоге у нас получился некий набор системных изменений, среди которых мы попытаемся выбрать именно те, которые могут относиться к следам подключения USB устройств. Выбранный мною метод имеет и свои недостатки, поскольку наблюдения за активностью системы применительно к USB устройствам не проводилось "в динамике", то есть мы не работали с открытыми с подключаемого носителя файлами (.docx/.xlsx) в различных пользовательских приложениях, а это могло привести к тому, что мы можем упустить факты попадания частей информации с USB-носителя в файлы подкачки, различные временные файлы кеша и файлы иного назначения. Поэтому материал, скорее всего, потребует последующей доработки.

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

История в файлах

После изучения изменений файловой части системных изменений, подтвердился факт того, что в операционной системе Windows 7 все действия над устройствами отражаются в следующих журнальных файлах:

  • %Windir%\setupact.log -- содержит сообщения отладки от инсталятора драйверов режима ядра, который представляет собой обычную Win32 DLL, сопровождающую процесс установки устройства;
  • %Windir%\inf\setupapi.app.log -- содержит сообщения процесса инсталляции приложений;
  • %Windir%\inf\setupapi.dev.log -- содержит сообщения процесса инсталляции устройств;

Начнем с файла setupapi.dev.log, по информации из которого мы можем отследить всю историю подключения к компьютеру любых устройств (не только USB). Я приведу фрагмент инсталляции описанного нами флеш-накопителя SanDisk Cruzer mini. Сразу предупрежу, что в файле setupapi.dev.log очень много информации, поэтому для поиска в ручном режиме можно отрыть его встроенным Блокнотом и при помощи комбинации клавиш Ctrl+F выполнить поиск словосочетания Device Install или USB\VID_. Это не самый удобный метод удобно, однако знать о нем определенно следует. Вот что удалось обнаружить:

Как можно заметить, подключении нового устройства в файле выделено в секцию, которая начинается с ключевой фразы Boot Session. Сессия загрузки, похоже, определяет к какой именно из многочисленных загрузок ОС относятся все входящие в неё действия. Затем, в строке (4), содержащей Device Install нас может заинтересовать значение USB\VID_0781&PID_5150\200411009307E9614ADD, которое определяет идентификатор устройства. Фактические же дату и время установки устройства мы можем определить по строке, начинающейся со словосочетания Section start YYYY/MM/DD HH:MM:SS.MMM, определяющего начало секции инсталляции устройства.
Далее по тексту мы можем наблюдать не менее интересную информацию:

Тут мы видим, что на начальном этапе инсталляции устройства утилита drvinst.exe создает узел драйвера, о чем красноречиво говорит нам строка Created Driver Node. Я так понимаю, запись об узле устройства создается в реестре. Тут же присутствует поле DevDesc, которое указывает нам на наименование инсталлируемого устройства Запоминающее устройство для USB. Здесь же, в строке 3, мы можем наблюдать HardwareID, содержащий значение USB\Class_E0&SubClass_01&Prot_03, которое идентифицирует класс устройства. В этот самый момент в реестре, с использованием строки HardwareID создается уникальный ключ, описывающий устройство.

История в реестре

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

HKLM\SOFTWARE\Microsoft\Windows Portable Devices\Devices

В этом ключе располагаются подключи, описывающие все когда-либо устанавливаемые в системе переносные устройства, принадлежащие к классу Windows (Windows Portable Devices).

Начиная с Windows XP в систему был включен новый класс устройств - портативные устройства Windows (Windows Portable Devices, WPD), который подразумевал расширение функций взаимодействия с мобильными устройствами, позволял использование программного интерфейса WPD и объектной модели автоматизации WPD.

Подключи и имеют следующую структуру: WPDBUSENUMROOT#UMB#2&37C186B&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_SANDISK&PROD_CRUZER_MINI&REV_0.1#200411009307E9614ADD&0#. Как мы видим, подключ однозначно указывает нам на вновь подключенный накопитель компании SanDisk, содержит в имени название производителя, модели, ревизию, серийный номер устройства.

HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses

В этом ключе находятся все глобальные уникальные идентификаторы (GUID, Globally Unique IDentifier) классов устройств.

Начиная с Windows 2000, с целью структурирования привязок оборудования в системном реестре, были введены так называемые идентификаторы классов устройств (Device Classes GUID).

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

GUID класса Отношение
{53f56307-b6bf-11d0-94f2-00a0c91efb8b} GUID_DEVINTERFACE_DISK. Диски
{53f5630d-b6bf-11d0-94f2-00a0c91efb8b} GUID_DEVINTERFACE_VOLUME. Тома
{6ac27878-a6fa-4155-ba85-f98f491d4f33} GUID_DEVINTERFACE_WPD. WPD-устройства
{f33fdc01-d1ac-4e8e-9a30-19bbd4b108ae} GUID_DEVINTERFACE_WPD. WPD-устройства
{a5dcbf10-6530-11d2-901f-00c04fb951ed} GUID_DEVINTERFACE_USB_DEVICE. USB-накопители

Оказывается при инсталляции одного-единственного USB устройства создается сразу несколько подключей, принадлежащих разным классам. Внутри подключа {53f56307-b6bf-11d0-94f2-00a0c91efb8b} создаются подключи, в имени содержащие путь ##?#USBSTOR#Disk&Ven_SanDisk&Prod_Cruzer_Mini&Rev_0.1#200411009307E9614ADD&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}
Аналогичным образом, подключ {53f5630d-b6bf-11d0-94f2-00a0c91efb8b}, относящийся к классам томов, содержит подключи с именем каждого тома, который в данный момент смонтирован в системе, а USB-накопитель у нас определенно прописывается в системе в качестве тома. Выглядит запись следующим образом: ##?#STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_SANDISK&PROD_CRUZER_MINI&REV_0.1#200411009307E9614ADD&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}
Однако, следует учитывать, что запись в ключе Volume GUID присутствуют в реестре только когда устройство подключено, при отключении том демонтируется, поэтому система записи удаляет!

HKLM\System\CurrentControlSet\Enum

Абсолютно все без исключения, когда-либо пронумерованные устройства, подключаемые к компьютеру и конфигурируемые PnP-менеджером, отображаются в ветви реестра HKLM\System\CurrentControlSet\Enum
Если же сфокусироваться только лишь на интересующих нас в данном контексте USB-устройствах, то стоит обратить внимание на подключи с именами USB, USBSTOR, STORAGE и WpdBusEnumRoot.

HKLM\System\CurrentControlSet\Enum\USB

Подключ USB содержит подключи, описывающие вообще все пронумерованные USB-устройства системы. В нем располагается иерархия вложенности, формируемая на основе параметров устройств, таких как HardwareID и InstanceID. Обычно подобная иерархия имеет вид HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\<hardware id>\<instance id>\, где InstanceID обычно принимает значение серийного номера устройства, либо других параметров в случае отсутствия последнего. К примеру, тут может располагаться подключ вида VID_15A9&PID_002B, который имеет уже свою собственную вложенную иерархию параметров, однозначно описывающих устройство.

usb enum

соответственно в подключе 0123456789ABCDEF (серийный номер) мы можем видеть детальную информацию по устройству:
usb enum свойства

HKLM\System\CurrentControlSet\Enum\USBSTOR

В подключе USBSTOR отображаются подключаемые накопители с интерфейсом USB. Формат вложенных подключей может быть близок к следующему: Disk&Ven_SanDisk&Prod_Cruzer_Mini&Rev_0.1.

HKLM\System\CurrentControlSet\Enum\STORAGE

В подключе STORAGE тоже содержатся артефакты по истории подключения USB устройств. В нем содержится подключ Volume, который, в свою очередь, содержит подключи всех накопителей, подключенных в системе в качестве томов. Подключи формируются в форме _??_USBSTOR#Disk&Ven_SanDisk&Prod_Cruzer_Mini&Rev_0.1#200411009307E9614ADD&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

HKLM\System\CurrentControlSet\Enum\WpdBusEnumRoot

Подключ WpdBusEnumRoot имеет вложенный подключ UMB, который, в свою очередь, содержит подключ с именем 2&37c186b&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_SANDISK&PROD_CRUZER_MINI&REV_0.1#200411009307E9614ADD&0#

HKLM\SYSTEM\MountedDevices

В реестре присутствует ключ HKLM\SYSTEM\MountedDevices, который содержит подключи, описывающие все когда-либо смонтированные в системе накопители. Выглядят они как \??\Volume{0db0a220-6908-11e5-9e0b-005056c00008}, имеют тип REG_BINARY и содержат в своем значении информацию (UTF) о пути, наименовании и GUID накопителя. К тому же, в этом же ключе присутствуют такие интересные параметры как \DosDevices\X:, где буква (X:) после обратного слеша означает имя тома. Параметров может быть несколько, обычно по количеству подключенных в системе букв дисков. У всех этих параметров значением будет путь к последнему сопоставленного с данной литерой физическому устройству, опять же в вышеприведенном формате.

HKU\{SID}\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Куст HKEY_USERS предназначен для хранения данных, специфичных для конкретного пользователя, зарегистрированного в системе. Соответственно, в первом уровне вложенности перечисляются SID пользователей, которые для обычных интерактивных пользователей, традиционно, принимают значения вида S-1-5-21-3284554473-1169922948-3718263881-1000. В ключе HKEY_USERS\{SID-пользователя}\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 располагаются GUID накопителя, что фактически раскрывает факт подключения дискового устройства.

  • Поделиться:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *