Ни для кого уже не секрет, что информация о разного рода активности многочисленных компонентов операционной системы попадает в реестр и файлы в виде записей заданного формата. При этом, информация эта нередко содержит чувствительные пользовательские данные: историю посещенных браузером страниц, кеш данных программ, информацию о подключаемых устройствах и многое многое другое. Во основном журналирование обеспечивается функциональными особенностями пользовательских программ, которые имеют встроенные алгоритмы сохранения истории операций, отчасти это возможно благодаря архитектурным особенностям ядра/HAL операционной системы, которые, производя конфигурирационные действия с устройствами, сохраняют информацию о последних в виде записей в системном реестре. Из всего многообразия подобной информации, в рамках данной статьи нас будет интересовать исключительно история использования USB устройств.
Система создает артефакты в момент обнаружения (инициализации) устройства (сменных накопителей, модемов, гаджетов, камер, медиаплееров и прч.) на шине компьютера. Дополнительным плюсом данного материала будет возможность сбора доказательной базы по факту неправомерного использования рабочей станции пользователя в корпоративной среде при помощи незадекларированных USB-устройств.
Не так давно в нашу жизнь вошел интерфейс USB, привнеся в неё довольно существенные изменения. Неожиданно многие вещи стали проще, отпала необходимость инсталляции устройства во внутренний интерфейсный разъем (шина), или внешний интерфейс, требующий перезагрузки станции для корректной инициализации устройства, да и сам процесс конфигурирования устройств стал, во множестве случаев, тривиальнее. На интерфейсе USB появились тысячи разнообразных по назначению устройств, которые достаточно было подключить к разъему на панели корпуса, после чего от момента подключения до состояния "готов к работе", порой проходили считанные минуты. Наряду с очевидными достоинствами: легкостью конфигурирования/использования, компактностью, функциональностью, подобные устройства сразу стали источником проблем как для безопасности персональных данных самого пользователя, так и безопасности корпоративных сред. Компактный, легко маскируемый "брелок" с интерфейсом USB может запросто явиться той ахиллесовой пятой, которая станет причиной "падения" гиганта корпоративной безопасности. Если порты USB в корпоративных рабочих станциях находятся без надлежащего контроля со стороны политик безопасности, то любое приспособление может запросто выступить в качестве средства для обхода периметра безопасности компании. И тут уж насколько хватит фантазии "взломщика", например, достаточно пронести на флешке свежий, не определяемый антивирусами вредоносный код и выполнить его (умышленно или нет), и вот вам уже прецедент, поскольку даже без локальных административных привилегий учетной записи пользователя сохраняется пространство для маневра. Не меньшую опасность представляют и USB-модемы, которые, в случае установки (а при использовании локальных/доменных политик по умолчанию это достигается достаточно просто), могут выступить в роли неконтролируемого канала передачи данных, по которому может осуществляться передача чувствительной корпоративной информации за пределы защищенного внутреннего периметра. При этом, даже декларируемые (заявленные/согласованные) пользовательские устройства (например, телефоны) могут содержать в своих микропрограммах или операционных системах уязвимости, которые, в случае эксплуатации, наносят вред не только владельцу, но и могут выступать в роли средства несанкционированного доступа к служебным данным. Поэтому, в случае возникновения инцидента информационной безопасности, связанного с эксплуатацией USB-устройств,
В связи со всем перечисленным, достаточно важно не только уметь ограничивать использование устройств, но и иметь доступ к истории USB подключений в системе. Этому вопросу и будет посвящена данная статья. Сразу оговорюсь, что весь список точек создания информации о подключении тех или иных устройство чрезвычайно обширен, поэтому по теме данной статьи мы будем рассматривать лишь историю использования USB устройств.
Перечисление (энумерация) USB устройств
Поскольку я сам в данном вопросе "плаваю", перед тем как перейти к практике, предлагаю немного усилить нашу теоретическую базу и описать терминологию, которая будет использоваться на протяжении всего материала. Сразу оговорюсь, что мы не будем освещать все виды взаимодействия, выполняющиеся на шине USB на аппаратном уровне, а сосредоточимся исключительно на основных понятиях, относящихся к USB-устройствам и требующихся нам для понимания практической стороны вопроса.
Подключение любого нового оборудования сопряжено с выполнением модулями ядра системы Windows предопределенных фаз опроса и инициализации. Начинается всё с того, что при подключении устройства к разъему USB, контроллером USB (встроенным в чипсет на материнской плате) генерируется аппаратное прерывание. Драйвер USB, ответственный за обработку данного прерывания, запрашивает статус порта, и если статус указывает на подключенное устройство, то ответственными подсистемами ядра производится последовательность действий, которую условно можно разделить на две стадии:
- Нумерование устройства;
- Установка драйвера устройства;
Ядро (?) инициирует к вновь подключенному устройству серию запросов GET_DESCRIPTOR с различными типами запрашиваемых дескрипторов (Device, Configuration, LangID, iProduct). Запросы опрашивают устройство на предмет наличия серии дескрипторов, представляющих собой структуры данных, описывающие возможности 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 и более поздние запрашивают этот строковый дескриптор у устройства при первом его подключении.
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 подключений. С целью выявления следов подключения USB стоит отследить абсолютно все изменения, происходящие в системе в момент подключения USB устройства. С этой целью на просторах Сети была найдена замечательная утилита под названием SysTracer, которая обладает всем необходимым функционалом. Утилита настолько проста и функциональна, что во многих случаях она окажется незаменимым средством в руках специалиста, поскольку предоставляет возможность сделать КРАЙНЕ полезное действие: создать мгновенный снимок (snapshot) состояния ключевых компонентов системы, таких как реестр и файлы. В качестве системы я использовал чистую инсталляцию Windows 7 Professional, при этом главным требованием было отсутствие каких-либо подключений внешних носителей. Итак, делаем снимок чистой системы, затем вставляем тестовую USB-флешку SanDisk Cruzer mini 1.0Gb и через некоторое время делаем второй снимок. Встроенными средствами утилиты SysTracer сравниваем полученные образы с выводом отчета. В итоге у нас получился некий набор системных изменений, среди которых мы попытаемся выбрать именно те, которые могут относиться к следам подключения USB устройств. Выбранный мною метод имеет и свои недостатки, поскольку наблюдения за активностью системы применительно к USB устройствам не проводилось "в динамике", то есть мы не работали с открытыми с подключаемого носителя файлами (.docx/.xlsx) в различных пользовательских приложениях, а это могло привести к тому, что мы можем упустить факты попадания частей информации с USB-носителя в файлы подкачки, различные временные файлы кеша и файлы иного назначения. Поэтому материал, скорее всего, потребует последующей доработки.
История в файлах
После изучения изменений файловой части системных изменений, подтвердился факт того, что в операционной системе Windows 7 все действия над устройствами отражаются в следующих журнальных файлах:
- %Windir%\setupact.log -- содержит сообщения отладки от инсталятора драйверов [режима ядра], сопровождающего процесс установки устройства;
- %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_. Это не самый удобный метод, тем не менее иметь его в арсенале определенно следует. Вот что удалось обнаружить:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
. . . [Boot Session: 2017/04/08 17:46:19.375] >>> [Device Install (Hardware initiated) - USB\VID_0781&PID_5150\200411009307E9614ADD] >>> Section start 2017/04/08 17:57:25.313 ump: Creating Install Process: DrvInst.exe 17:57:25.313 ndv: Retrieving device info... ndv: Setting device parameters... ndv: Searching Driver Store and Device Path... dvi: {Build Driver List} 17:57:25.391 dvi: Searching for hardware ID(s): dvi: usb\vid_0781&pid_5150&rev_0010 dvi: usb\vid_0781&pid_5150 dvi: Searching for compatible ID(s): dvi: usb\class_08&subclass_06&prot_50 dvi: usb\class_08&subclass_06 dvi: usb\class_08 . . . |
Как можно заметить, подключении нового устройства в файле выделено в секцию, которая начинается с ключевой фразы Boot Session. Сессия загрузки, похоже, определяет к какой именно из многочисленных загрузок ОС относятся все входящие в неё действия. Затем, в строке (4), содержащей Device Install, нас может заинтересовать значение USB\VID_0781&PID_5150\200411009307E9614ADD, определяющее идентификатор устройства. Фактические же дату и время установки устройства мы можем определить по строке, начинающейся со словосочетания Section start YYYY/MM/DD HH:MM:SS.MMM, определяющего начало секции инсталляции устройства.
Далее по тексту мы можем наблюдать не менее интересную информацию:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
. . . dvi: Created Driver Node: dvi: HardwareID - USB\Class_08&SubClass_06&Prot_50 dvi: InfName - C:\Windows\System32\DriverStore\FileRepository\usbstor.inf_x86_neutral_de27b3e85e2c60fc\usbstor.inf dvi: DevDesc - Запоминающее устройство для USB dvi: DrvDesc - Запоминающее устройство для USB dvi: Provider - Microsoft dvi: Mfg - USB-совместимое запоминающее устройство dvi: ModelsSec - Generic.NTx86 dvi: InstallSec - USBSTOR_BULK dvi: ActualSec - USBSTOR_BULK.NT dvi: Rank - 0x00ff2000 dvi: Signer - Microsoft Windows dvi: Signer Score - INBOX dvi: DrvDate - 06/21/2006 dvi: Version - 6.1.7601.19144 inf: Searched 1 potential matches in published INF directory inf: Searched 35 INFs in directory: 'C:\Windows\inf' dvi: {Build Driver List - exit(0x00000000)} 17:57:25.540 . . . |
Тут мы видим, что на начальном этапе инсталляции устройства утилита 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).
Подключи и имеют следующую структуру: 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) классов устройств.
Поскольку 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, который имеет уже свою собственную вложенную иерархию параметров, однозначно описывающих устройство.
соответственно в подключе 0123456789ABCDEF (серийный номер) мы можем видеть детальную информацию по устройству:
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 накопителя, что фактически раскрывает факт подключения дискового устройства.