msuhanov Jan 23 2017 at 09:15

Аппаратные или программные блокираторы записи — что надежнее?

14 min

15K

BI.ZONE corporate blogInformation Security*

Являются ли аппаратные блокираторы записи более надежными по сравнению с программными?

Предисловие

Проведение криминалистических исследований при расследовании инцидентов информационной безопасности, производство судебных экспертиз и многие другие направления деятельности, связанные с компьютерной криминалистикой, требуют максимально возможного сохранения целостности исследуемых данных. Для этого используются блокираторы записи — программы или устройства, не позволяющие записать что-либо на исследуемый накопитель. Необходимость применения таких средств происходит как из требований процессуального законодательства (например, УПК РФ), так и из различных рекомендаций методического и иного характера, а также из стандартов (например, СТО БР ИББС-1.3-2016). Некоторые аспекты функционирования блокираторов записи и будут рассмотрены в настоящей статье.

Один из ранних аппаратных блокираторов записи (2002 год)

Введение

Многие специалисты по компьютерной криминалистике и юристы разделяют мнение, что аппаратные блокираторы записи являются более надежными, чем программные блокираторы записи; это суждение еще можно найти, прямо или косвенно, в различных публикациях ¹²³. В этой статье я постараюсь раскрыть внутреннее устройство аппаратных и программных блокираторов записи, показав различные проблемы, существующие в данных продуктах.

Принципы функционирования

Аппаратные блокираторы записи

Все аппаратные блокираторы записи могут быть разделены на две группы в зависимости от того, как они обрабатывают команды, полученные от хоста:

работающие на базе белого списка;
работающие на базе черного списка.

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

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

Кроме того, все аппаратные блокираторы записи могут быть разделены на две другие группы в зависимости от деталей их реализации:

работающие в качестве транслятора команд;
работающие в качестве модулей, предоставляющих доступ к блочному устройству.

Аппаратный блокиратор записи работает в качестве транслятора команд, когда он просто транслирует разрешенные команды, полученные от интерфейса-источника, путем их повторения в интерфейс-получатель. Например, простой блокиратор записи типа SATA-to-USB может получать SCSI-команды от USB-интерфейса (использующего набор команд «SCSI transparent command set» для класса «mass storage»), а затем для каждой разрешенной SCSI-команды производить запрос SATA-контроллеру через AHCI, перенаправляя любые ответы обратно хосту по протоколу SCSI.

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

Кроме того, аппаратные блокираторы записи могут предоставлять особые функции для некоторых типичных и нетипичных применений:

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

Программные блокираторы записи

Детали реализации программных блокираторов записи зависят от используемой операционной системы. В операционных системах, работающих в реальном режиме, вроде DOS, программные блокираторы записи перехватывают прерывание BIOS 0x13, используемое для чтения и записи данных диска, отфильтровывая запросы на запись и вызывая исходный обработчик прерывания для запросов на чтение. Современные операционные системы вроде Windows и GNU/Linux используют драйверы прямого доступа для взаимодействия с накопителями, прерывание BIOS 0x13 используются загрузчиком для чтения ядра и других данных (вроде драйверов прямого доступа) только на раннем этапе загрузки. Таким образом, существуют множество путей для реализации функциональности блокировки записи, например:

драйвер, работающий в режиме «только чтение», для определенного класса накопителей (PATA, SATA, SCSI, USB и др.);
программа (драйвер), отфильтровывающая запросы на запись на их пути к драйверу определенного класса накопителей более низкого уровня;
драйвер, предоставляющий блочное устройство в режиме «только чтение» для выбранного накопителя или раздела, с параллельным существованием в операционной системе блочного устройства в режиме «чтение-запись» для того же накопителя или раздела (предполагается, что использование различных программ будет происходить применительно к блочному устройству в режиме «только чтение»).

В зависимости от реализации, программные блокираторы записи могут анализировать или блокировать следующие виды запросов:

чтение, запись, сброс кеша и другие запросы в унифицированном формате, специфичном для операционной системы (который не основан на протоколе взаимодействия с накопителем на низком уровне);
запросы в формате, основанном на протоколе, используемом для взаимодействия с накопителем (например, SCSI), или который напрямую реализует данный протокол.

Кроме того, программный блокиратор записи может представлять накопитель операционной системе с пометкой «только чтение».

В современных операционных системах были встречены следующие реализации блокировки записи:

Windows:

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

Linux:

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

При работе с запросами, сформированными на базе родного протокола (вроде SCSI в Windows), программный блокиратор записи может работать с черными и белыми списками, как было показано ранее.

В целом, программные блокираторы записи должны перехватывать запросы или в одной точке (например, перед передачей запроса одному из многих драйверов накопителей), или во всех местах сразу (например, во всех драйверах накопителей).

Следует отметить, что программный блокиратор записи не может перекрыть все возможные пути передачи небезопасной команды накопителю. Например, ядро может предоставлять интерфейс для отправки «сырых» запросов накопителю (вроде интерфейса SG_IO в Linux), или архитектура драйверов накопителей может позволять какому-либо драйверу отправить запрос в обход фильтрующего драйвера (как в Windows), или низкоуровневый драйвер может самостоятельно отправлять небезопасные команды, или какая-либо программа может просто отключить блокиратор записи. И хотя можно предпринять некоторые меры против таких недостатков, идея проста — всегда существует путь, обходящий программный блокиратор записи.

Программные квазиблокираторы записи

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

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

Сравнение аппаратных блокираторов записи с программными

Могут быть отмечены следующие важные различия между аппаратными и программными блокираторами записи:

Аппаратные блокираторы записи делают разрыв между хостом и накопителем, в результате небезопасные команды от хоста подлежат блокированию вне зависимости от их происхождения. Программные блокираторы записи могут быть обойдены вредоносной программой, как было показано ранее.
Программные блокираторы записи для драйверов прямого доступа неактивны во время раннего этапа загрузки: блокировка записи отсутствует, когда загрузчик использует прерывание BIOS 0x13 или сервисы EFI для загрузки ядра и других компонентов современной операционной системы. В то же время аппаратные блокираторы записи до завершения их инициализации не обрабатывают какие-либо команды.

Есть мнение, что программные блокираторы записи не могут быть надежными, потому что зависят от хрупкой программной среды: например, обновление операционной системы, или обновление драйвера, или ошибка (в аппаратном или программном обеспечении) может препятствовать механизму блокировки записи; аппаратные блокираторы записи, с другой стороны, считаются надежными, потому что содержат стабильное, хорошо протестированное аппаратное обеспечение и встроенное программное обеспечение⁴.

Проверка криминалистической правильности

Программные квазиблокираторы записи

SUMURI PALADIN 4.01

PALADIN — это не требующий установки дистрибутив (основанный на Linux), разработанный для загрузки исследуемого компьютера с целью предварительного просмотра данных или их сбора. Кроме того, этот дистрибутив может использоваться на криминалистической рабочей станции в качестве уже готовой операционной системы.

Согласно документации, доступной в PALADIN 4.01, PALADIN был модифицирован для защиты от записи всех подключенных накопителей после начала загрузки («PALADIN has been modified to write-protect all attached media upon boot»). Тем не менее, данная версия не содержит какого-либо компонента, блокирующего запись; также были выявлены следующие факты записи на подключенные накопители во время загрузки дистрибутива (этот и последующие разделы не содержат исчерпывающего списка обнаруженных проблем (недостатков), указываются только некоторые характерные проблемы; по той же причине аналогичные проблемы в других криминалистических продуктах на основе Debian, Ubuntu и других дистрибутивов не указаны):

если подключенный накопитель содержит «грязную» (не отмонтированную должным образом) файловую систему Ext3/4, то эта файловая система восстанавливается с помощью ее журнала;
если подключенный накопитель содержит «грязную» файловую систему NTFS, то журнал ($LogFile) этой файловой системы очищается.

Эти проблемы относятся к раннему этапу загрузки не требующих установки дистрибутивов на базе Ubuntu или Debian, когда программы в стартовой (начальной) файловой системе (initial RAM file system) запускаются с целью найти загрузочный накопитель путем монтирования файловых систем на каждом накопителе (включая объекты исследования) и поиска определенных сигнатур в этих файловых системах (вроде файла, содержащего определенный UUID). Эти действия необходимы для завершения перехода с прерывания BIOS 0x13 или сервисов EFI, используемых загрузчиком, на драйверы прямого доступа, используемые ядром для чтения с загрузочного накопителя.

Хотя такие проблемы присутствуют в этой и других версиях PALADIN, данный дистрибутив прошел валидацию NIST без каких-либо замечаний о данных проблемах⁵.

Программные блокираторы записи

SUMURI PALADIN 6.01

PALADIN 6.01 включает компонент ядра (Linux) для блокирования записи, который был негласно включен без каких-либо упоминаний в документации или в журнале изменений. Этот компонент был негласно исключен из более поздних версий данного дистрибутива (например, PALADIN 6.07).

Во время валидации была обнаружена следующая ошибка в реализации блокировки записи: на раннем этапе загрузки, когда запускаются программы из стартовой файловой системы, компонент блокировки записи блокирует запросы на запись и высвобождение (discard), адресованные всем блочным устройствам со старшим номером 8 (и только). В такой реализации только накопители PATA/SATA/SCSI/USB защищены от записи на указанном этапе загрузки, в то же время, например, носители в считывателях карт (MMC) не защищены от записи, а потому подвержены действию проблемных моментов, указанных ранее.

Аппаратные блокираторы записи

Криминалистический дупликатор Tableau TD3

Криминалистический дупликатор Tableau TD3 (версия программного обеспечения: 2.0.0) может быть использован в качестве сетевого блокиратора записи, открывающего доступ к подключенному исследуемому накопителю по протоколу iSCSI. Драйвер iSCSI блокирует запросы на запись, адресованные исследуемому накопителю, при этом компонент блокировки записи в ядре (Linux) или в аппаратном обеспечении отсутствует. Было обнаружено, что подключение накопителя с файловой системой Ext4, в журнале которой зафиксирована ошибка I/O, приводит к отправке дупликатором нескольких команд записи (модифицирующих файловую систему) через «заблокированный от записи» порт, потому что используемая дупликатором операционная система (на основе Linux) автоматически монтирует файловые системы на накопителе, подключенном через «заблокированный от записи» порт.

Криминалистический мост Tableau T356789iu

Криминалистический мост Tableau T356789iu (версия программного обеспечения: 1.3.0) блокирует попытки чтения хостом секторов, прилегающих к плохому. Было обнаружено, что один плохой сектор на подключенном накопителе приводит к тому, что 128 плохих секторов не могут быть прочитаны хостом якобы из-за ошибки чтения. Установлено, что криминалистический мост использует функциональность упреждающего чтения и кеширования ядра (Linux) при чтении данных с подключенного накопителя (ядро может прочитать и отправить в кеш содержимое секторов до того, как оно будет запрошено программой, запросы на чтения обрабатываются через кеш), а ядро имеет плохое «размельчение» ошибок (оно не перечитывает отдельные секторы внутри большого кешируемого блока после ошибки чтения этого блока).

Криминалистический мост Tableau T35es

Согласно информации от компании Guidance Software⁶, криминалистические мосты Tableau T35es со старой версией программного обеспечения разрешали передачу SCSI-команд WRITE(16), полученных от хоста через USB-соединение, в адрес подключенного накопителя. Эта проблема является примером недостатка работы на базе черного списка.

Криминалистический мост Tableau T8-R2

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

Выводы

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

По моему мнению, нужно учесть и реализовать следующее:

сообществу нужны улучшенные методологии и методы валидации специализированного программного обеспечения;
эти методы должны покрывать все типовые случаи применения специализированного программного обеспечения;
эти методы не должны опираться только на тестирование «черного ящика»;
разработчики специализированного программного обеспечения не должны скрывать подтвержденные ими проблемы, а равно скрытно исправлять ошибки.

Почему нам нужны улучшенные методологии и методы валидации специализированного программного обеспечения?

Ответ простой: текущие методологии и методы не удовлетворяют текущим требованиям сообщества.

Методологии и методы тестирования программных блокираторов записи, опубликованные NIST⁸⁹, не затрагивают механизмы блокировки записи в операционных системах на базе Linux, а равно не затрагивают другие проблемы, существующие в не требующих установки дистрибутивах на базе Windows и Linux (вроде автоматического исполнения кода с объекта исследования во время загрузки с USB-накопителя за счет выбора исследуемого накопителя в качестве загрузочного или использования файловой системы на исследуемом накопителе в качестве содержащей обновления, применяемые автоматически к загружаемой программной среде).

Методология тестирования и сопутствующие документы для аппаратных блокираторов записи, опубликованные NIST¹⁰¹¹, не фокусируются на ситуации, в которой аппаратный блокиратор записи самостоятельно, без соответствующей команды от хоста, пишет на подключенный накопитель. Проблемы с «размельчением» ошибок также не затрагиваются этими документами. В целом, методы тестирования аппаратных блокираторов записи, упомянутые ранее, подразумевают, что аппаратный блокиратор записи является транслятором команд.

Почему нам нужны методы, покрывающие все типовые случаи применения?

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

Например, в NIST не зафиксировали проблемы с модификацией данных в PALADIN 4.0, потому что проведенные тесты не включают в себя «грязные» файловые системы. Вместе с тем «грязные» файловые системы — это обычная ситуация в ходе криминалистических исследований (например, после выключения компьютера методом прерывания электропитания).

В двух недавних отчетах, опубликованных NIST¹²¹³, написано, что некоторые не требующие установки дистрибутивы были протестированы в сочетании с аппаратными блокираторами записи, но типовые случаи применения подобных дистрибутивов включают копирование данных без аппаратного блокиратора записи (например, когда накопитель нельзя извлечь из компьютера или его невозможно подключить к аппаратному блокиратору записи). Очевидно, что результаты в этих отчетах не могут быть экстраполированы на копирование данных без аппаратного блокиратора записи.

Почему нам нужны методы, не опирающиеся только на тестирование «черного ящика»?

Потому что число типовых случаев применения превышает реальные возможности.

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

Учитывая данный факт, реальнее идентифицировать слабые места с использованием подхода с «белым ящиком», а затем разработать наборы тестов для «черного ящика».

Почему мы хотим, чтобы разработчики раскрывали подтвержденные ими проблемы и реализованные ими исправления ошибок?

Конечно, изменение данных на объектах исследования не приводит автоматически к признанию таких доказательств недопустимыми. Например, копирование информации из мобильных устройств и с работающих систем подразумевает внесение изменений в данные на оригинальном накопителе с целью получения доступа к этим же данным. Но такие способы копирования не могут служить оправданием для изменений, вносимых средствами, от которых это не ожидается (хотя даже такие изменения еще не делают доказательства недопустимыми во всех случаях).

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

Ссылки

1. Nikkel B. Practical forensic imaging. 2016.
2. Morton T. Introduction to Digital Forensics. 2011.
3. Al Falayleh M. и Al-Karaki J. On the Selection of Write Blockers for Disk Acquisition: A Comparative Practical Study. 2013.
4. Menz M. и Bress S. The Fallacy of Software Write Protection in Computer Forensics. 2004.
5. NIST. Test Results for Digital Data Acquisition Tool: Paladin 4.0. 2014.
6. Guidance Software. Tableau Firmware Update: TFU v6.80. 2010.
7. Guidance Software. Tableau Firmware Update: TFU v6.84. 2011.
8. NIST. Software Write Block Tool Specification & Test Plan. 2003.
9. NIST. ACES Test Suite User’s Guide. 2008.
10. NIST. Hardware Write Blocker (HWB) Assertions and Test Plan. 2005.
11. NIST. Hardware Write Blocker Device (HWB) Specification. 2004.
12. NIST. Test Results for Disk Imaging Tool: Paladin v6.09. 2016.
13. NIST. Test Results for Disk Imaging Tool: Paladin v6.08. 2016.

Tags:

Hubs: