Я еще раз напомню, что перечислил источники, в которых имени этой константы нет (я сам их изучал, т. к. вопрос происхождения константы стоял остро). В Интернете можно найти код с таким же названием константы, но этот код появился после обсуждаемого коммита.
Потому что ее убрали. Потому что ее все равно не использовали.
А если б и была Вы хотите одним именем одной константы доказать что-то? Серьезно?
Таких мест, я думаю, достаточно. Во всяком случае, это доказывает, что по крайней мере один разработчик ReactOS смотрел в утечку кода. И брал оттуда, по крайней мере, одну константу. И ничего вы (как проект) с этим не сделали (посмотрите хотя бы описание коммита, которым убрали эту константу).
Могу еще сказать, что в заголовочных файлах Windows часто раскрываются детали использования конкретных констант или полей (иногда это описание не соответствует действительности), т. е. «просто посмотреть в заголовочный файл» уже достаточно для того, чтобы получить информацию о внутренних деталях реализации.
Имена это не код, не алгоритмы. Они не содержат логики и сами по себе ничего не делают :)
Тем не менее, действие исключительного права распространяется и на заголовочные файлы. И еще раз: «Developers (devs) have not looked at Microsoft Windows™ source code».
Этим дело не ограничивается. Есть патч, в нем объявлена константа HFILE_TYPE_ALTERNATE. В WRK названия этой константы нет, в отладочных символах и в отладочных сборках ядра этого названия тоже нет, в официальном плагине для WinDbg (reg) этого названия тоже нет. Единственное место, где эта константа была определена, – это утечки кода (еще до WRK). Поскольку в оригинале было перечисление (а не набор из define) и это значение убрали, то в последующих версиях Windows (речь про XP и выше) этой константы не было даже в виде [пропущенного] числа где-то в коде.
Будем считать что операционисты в банках совершают звонки по изменению у клиента? Или нет?
Ох как бы меня послали все операционисты с которыми работал после таких заявлений. Проверить что ли по знакомым в организациях как часто им звонят из банков...
Простите, но: изменение одного параметра != попытка хищения. Как я уже говорил, один признак обычно не является показателем.
конечно она есть, вот только принималось не только для снижения банковских рисков. Может ткнете где в пункте 15 про такой сбор данных оператором.
Пункт про сбор данных лучше искать в пачке документов, регламентирующих ДБО. Начать можно с договора с банком.
Все комментарии на которые вы отвечали были про программы удаленного доступа, где RDP совсем не упоминалось.
Как в Windows реализован RDP? Программой, конечно же. Чем же еще? Далее читайте определение программы.
Очень большую имеет роль. Работа толстых клиентов посредством обмена пакетами просто не позволяют применять те скрипты о которых речь. Там нету ни браузера, ни поведения пользователя, а только несколько параметров.
И антифроды там совсем не эти скрипты по которые речь.
В «толстый клиент» можно добавить куда больше «антифрод»-функциональности, чем в «тонкий клиент». Можно даже драйвер загрузить. Вы точно разбираетесь в теме?
А тип действительно не важен, потому что с любым типом клиента можно работать удаленно. Сюрприз, да?
Конечно умею. Я вон сколько написал на что получил ответ «Именно так, как вы описали в том же абзаце чуть выше», но опровергаете только то где написал что в это не верю.
Про «веру» вы точно ничего не писали. Точно умеете читать?
Да неужели. Пусть у клиента работали по RDP, но если внезапно на компьютере стала активна программа «типа Radmin или Ammy», а обычно ее нету — то нужно брать на заметку.
Поздравляю, вы нашли второй признак (первым был факт наличия открытого порта): факт отсутствия открытого порта в прошлом. Попробуйте найти еще возможные признаки.
Вы какую учетную запись блокировать собрались? И с чего ее собрались блокировать?
Никакую. Просто кто-то считает, что одного из «подозрительных» признаков уже достаточно для блокировки со стороны банка. Я же написал, что нет. Перечитайте еще раз.
Вы про что речь ведете? Видели толстых клиентов? Когда весь функционал у клиента находится в его инфраструктуре, весь обмен банком с клиентом осуществляется посредством пакетов информации, и банковские сотрудники вообще не видят что творится у клиента?
Речь шла и про тонкие клиенты в том числе. Тут тип клиента роли не играет.
И чтобы клиенты работали на терминальном сервере банка (по RDP) не разу не встречал.
Вы читать умеете? На стороне клиента банка стоит терминальный сервер, где есть клиент системы ДБО. Бухгалтер подключается к этому терминальному серверу и работает. Это не сервер банка, это сервер организации – клиента банка. И с него ведется работа с системой ДБО. Именно так, как вы описали в том же абзаце чуть выше.
И уже из-за наличия таких конфигураций один лишь факт работы на компьютере программы-сервера для удаленного управления (который определяется по открытому порту) не может играть решающей роли.
Более того, «антифрод»-скрипты умеют не только определять открытые порты, но и определять (с некоторой вероятностью, но все же довольно точно), что клиент работает в браузере через RDP/VNC и т. п.
В поле я работал с обоих сторон и около 20 лет, у вас какое-то другое поле.
Я работал именно в этом поле, в одной из компаний, которая в обсуждении здесь упоминалась.
Программами удаленными доступами любит пользоваться поддержка банка, т.к по телефонному разговору им тяжело работать, раньше до примерно 2010 года большинство обращений решалось только телефонным разговором или выездом на место, т.к. программы удаленного доступа были не очень распространены, или вообще запрещены к использованию на рабочих местах.
В большинстве случаев обнаруженный открытый порт, характерный для программы для удаленного управления компьютером, – это лишь один из признаков, а не немедленная блокировка учетной записи. Еще в том же 2010 году многие организации работали с системами ДБО через терминальный сервер (по RDP).
это бред, банку обычно все равно как совершается подключение. А совершать банком телефонные звонки еще больший бред т.к. усложнение работы операционистов и увеличение затрат (аля снижение прибыли) (за исключением больших сумм, но там другие правила проверки)
Кому-то все равно, а кому-то нет. Тем более, есть юридические риски (например, часть 15 статьи 9 ФЗ «О НПС»). Про «еще больший бред» комментировать даже не буду. ;-)
В NTFS есть набор характерных признаков, позволяющих определить факт «подкидывания» данных с компьютера (с Windows), на котором системное время установлено «задним числом». Есть еще ряд косвенных признаков (например, можно показать, что следов работы с искомым файлом нет или что файл записывали как на внешний накопитель).
А если кто-то пишет данные с помощью ntfs-3g, то, извините, каждый созданный файл будет иметь весьма кричащий «флаг» «я был записан не с помощью ntfs.sys».
Автор публикации не разделяет умышленную модификацию данных и случайную (или неосторожную) модификацию данных. «Предварительное тестирование» (в правильной терминологии – валидацию) программные и аппаратные средства проходят лишь в контексте случайной (или неосторожной) модификации данных. Строго говоря, УПК никаких требований к программным или аппаратным средствам не предъявляет и валидация, тем более в NIST, не имеет юридического значения (был законопроект по обязательной валидации средств судебной экспертизы, но это все еще законопроект, который не могут принять уже годы, впрочем, механизм валидации в законопроекте – это весьма сомнительная с точки зрения эффективности вещь).
Вот я понятой. Смотрю на флешку. Как я знаю, что там считается только контрольная сумма, а не подкладывается ГлавныйСекрет(2).rar во все файловые системы ещё на этапе initrd самой флешки?
Никак. Защита от умышленного «подкидывания» данных только юридическая – специалист не должен быть заинтересован в исходе дела (в противном случае он подлежит отводу); существует уголовная ответственность за фальсификацию доказательств; специалист несет уголовную ответственность за дачу заведомо ложных показаний; лицо, у которого производится обыск, вправе наблюдать за процессом обыска и за действиями специалиста.
Понятой, если ему это принципиально, может настоять на включении в протокол подробных сведений о том, как копировались данные и (или) как считался от них хеш, а также описания «вилки достоверности» (специалист произвел именно те действия, которые наблюдал понятой, если введенные специалистом команды запускали исполняемые файлы, которые делали именно то, что должны были делать, каких-либо фоновых процессов, затрагивающих искомые данные, не было и т. п.). У понятого, во всяком случае, есть право делать замечания к протоколу, которое не может быть ограничено.
В принципе, если действия с данными производились только из определенного live-дистрибутива, то его носитель можно приобщить к протоколу обыска (например, чтобы подтвердить неизменность программы sha256sum), но на практике такого я не видел. Это, конечно, не исключает тему «закладок» в BIOS/UEFI (которые каким-то образом исказили данные) или тему подмены корневой ФС live-дистрибутива, но все-таки у всего, даже у сомнений, должен быть (и есть) разумный предел.
> А понятые могут и не иметь знаний в интересующей нас области.
Это сейчас так принято считать. А вот в статье 60 УПК написано, что понятой удостоверяет, в том числе, содержание следственного действия. Таким образом, понятой должен понимать, что делает специалист (иначе содержание следственного действия ему, понятому, не понятно).
Итого два сектора? Нет, MFT занимает гораздо больше пространства (строго говоря, один сегмент файловой записи MFT – это 1024 байта или 4096 байтов, а таких сегментов много, по одному на каждый файл как минимум).
АПМДЗ является частым случаем реализации одной из стадий поэтапного контроля. Это такой же кусок кода, как и сам winload. Они одновременно находятся в одной и той же памяти и исполняются одновременно на одном уровне привелегий. От того, что вы расположите их в одном PE или в разных ничего не поменяется.
Жаль, что вам не видно разницы. Потому что она есть, да еще и принципиальная. Сравните, как работают АМДЗ и реализации доверенной загрузки на базе Secure Boot (желательно еще с TPM и обеспечением целостности файловой системы через ее шифрование).
Secure Boot не будет пытаться что-то сделать с реестром Windows из UEFI. АМДЗ – будет, потому что ни менеджер загрузки, ни ядро не предоставляют интерфейс для контроля целостности на тех этапах, где это нужно.
Еще раз повторю: вы говорите о различиях в реализации парсинга в winload'е и АПМДЗ, что является частным случаем ошибки/уязвимости. Точно такие же ошибки есть в любом коде, будь то Secure Boot или любая другая система защиты.
Еще раз. Для Secure Boot не нужно иметь UEFI-драйвер для NTFS и реестра Windows. Для АМДЗ – нужно (если, конечно, не убирать поддержку Windows вообще, хотя и это оставляет необходимость поддерживать, например, FAT и Ext2/3/4).
Использование сторонних парсеров (драйверов) порождает атаки, которых в принципе нет в реализациях Secure Boot. Что, конечно, не исключает иных видов атак.
Ничего не мешает АПМДЗ проверять целостность реестра и наличие драйвера СЗИ уже в памяти по ExitBootServices. Можно использовать для проверки реестра в памяти куски кода winload'а, вызывая их из своего UEFI-модуля.
Очень хорошо, если у вас такое реализовано. Только вот ExitBootServices вызывается до загрузки некоторых критичных кустов реестра Windows. То есть ваш весьма сомнительный с точки зрения реализации способ уже не защищает от того, от чего должен защищать.
И еще. Код для работы с реестром в менеджере загрузки и в ядре тоже немного отличается. Например, в порядке применения журналов транзакций. Нельзя применять одно для контроля целостности того, что использует другое.
Куда разумнее подгружать библиотеку offreg (отлично работает под Wine), проводить контроль целостности с ее помощью, а затем сохранять куст в исходный файл (таким образом, все, что оказалось невидимым для offreg, останется невидимым и для контролируемой операционной системы). Только вот библиотеки offntfs нет.
Можно исполнять все, вплоть до получения управления драйвером в тонком гипервизоре (blue pill/bitvisor) и контролировать целостность всех исполняемых страниц памяти при их вызове (ага, мы так умеем).
Очень хорошо, что умеете. Тут уже возникают вопросы по поводу того, когда стартует гипервизор, можно ли его убрать теми атаками, про которые я веду речь, или нет.
На любой названный вами вектор атаки я всегда смогу ответить методом защиты. Это обычное соревнование брони и снаряда.
Не на вектор, а на конкретный недостаток. От вектора атаки предзагрузочный контроль целостности не защищает, хотя и можно обрабатывать конкретные пограничные случаи. Вот только есть ли у вас их список?
winload не умеет в файлы транзакций, так что ничем не отличается даже от аккорда. Незакрытые транзации закроет уже ядро, а все бутовые драйвера, загруженные winload'ом, получат управление.
Умеет. Берите отладочные символы и вперед: HvpApplyIncrementalLogFile, HvpApplyLegacyLogFile, HvAnalyzeLogFiles.
Незакрытые транзации закроет уже ядро, а все бутовые драйвера, загруженные winload'ом, получат управление.
Смотрите выше, ибо умеет. Отсутствие поддержки транзакций до ядра – это, простите, Windows 2000. В Windows XP уже поддержка есть и никуда не исчезала.
В модель угроз не входит возможность исполнить код в ядре, а без этого вы NTFS не поломаете.
В чью-то модель угроз? Если так, то это проблемы того, кто модель угроз писал. АМДЗ не нужен в таком случае вообще, достаточно драйвера для контроля целостности.
Ничего не забыл? Т.е. ни одна из предложенных вами атак в реальной жизни не сработает. Это вовсе не означает, что вы не сможете найти уязвимость.
Я не вижу смысла продолжать этот разговор. Я указал на вполне конкретные недостатки, описал общий вектор атаки, в который эти недостатки укладываются, а в ответ узнал лишь то, что winload вы не «реверсили», а потому, согласно вашему заблуждению, предложенные мной атаки не работают.
Почему вы считаете, что в модуле Secure Boot не может быть уязвимостей, а в таком же модуле UEFI, загружающемся из Option ROM обязательно будут?
Я так не считаю. Я лишь утверждаю, что поэтапный контроль лучше. Потому что целостность следующего компонента будет проверяться текущим компонентом (им или с его участием, если говорить точнее), а не каким-то сторонним компонентом, который может прочитать что-то не так, как надо.
Что, разумеется, не исключает существование каких-то уязвимостей и недостатков. Но в случае с АМДЗ проблема носит принципиальный характер.
На всякий случай уточню, что АПМДЗ точно также может проверять целостность загрузчика уже после загрузки в память.
Ядро, стартовую файловую систему, реестр Windows, модули ядра (драйверы), пользовательское окружение тоже модуль доверенной загрузки загружает? Нет. Модуль доверенной загрузки действительно передает управление загрузчику, который этот модуль и прочитал в память. А вот куст реестра SYSTEM модуль доверенной загрузки для ядра (или winload) не загружает.
3. Я не могу отвечать за все СЗИ под Windows на Российском рынке, но то, что я разрабатываю, работает больше похоже на Secure Boot: наш АПМДЗ контролирует целостность загрузчика, ядра и веток реестра, которые парсит загрузчик, а потом стартует наш бутовый драйвер, который контролирует целостность остального уже с использованием виндовых драйверов/функций ядра.
На всякий случай уточню, что изначально реестр винды грузит и парсит winload, а не ядро, вычитывая оттуда список бутовых драйверов, к которым относятся и все средства защиты.
То есть, сначала предзагрузочный компонент проверяет целостность некоторых частей реестра Windows (с использованием собственного парсера), затем передается управление менеджеру загрузки Windows, а потом, немного позднее, стартует ваш драйвер, который может проверить целостность того, что было проверено раньше, но уже с использованием функций ядра.
А теперь подумайте, что будет, если проверка целостности реестра на предзагрузочном этапе (до передачи управления менеджеру загрузки) пройдет успешно, но ваш драйвер будет вырезан (или заменен на «заглушку», если есть сторожевой модуль) из соответствующего куста реестра Windows (и предзагрузочный компонент этого не заметит, потому что смотрите выше). Собственно, приехали.
Драйвера файловых систем в АПМДЗ и целевом Linux'е, как вы понимаете, одинаковые.
Нет, не понимаю. Версии могут быть разными. Если вы «на лету» берете драйверы из стартовой файловой системы (а для этого нужно, как минимум, смонтировать /boot/), то да, драйверы будут теми же (при этом возникает вопрос, как таким драйверам доверять, но это уже можно решить).
Если отличий в реализации парсера реестра / драйвера NTFS в АПМДЗ и winload'е будет мало, а их поиск будет слишком дорогим, то проще будет выбрать другой вектор атаки.
Непаханое поле, пока что.
Бывает защита, пробивание которой стоит дороже, чем данные, которые она защищает.
Атакующий может целиться и не в защищаемые данные. Так что «цена данных» и «цена преодоления защиты» – это отстраненные понятия.
В этом случае АПМДЗ контролирует целостность ядра и initramfs (в котором СЗИ реализовано в виде LSM-модуля), а потом делает в него kexec, без всяких загрузчиков.
Если вы делаете так, то тут могут появиться и другие особенности (помимо разницы в работе парсеров и драйверов). Если, например, дистрибутив использует dracut, то я могу после контроля целостности оборудования подключить USB-накопитель и до окончания загрузки заменить оригинальное ядро (целостность которого была проверена) на свое (разумеется, при условии, что отладочная оболочка отключена и рутовый шелл в initramfs при сбое не получить). Но это уже другая история.
Secure Boot – это не об этом. На базе Secure Boot можно реализовать поэтапный контроль целостности (подпись менеджера загрузки проверяется микропрограммой, менеджер загрузки проверяет подпись ядра, стартовой файловой системы и т. д.), который вполне будет работать. Какие-то пробелы в этом процессе есть (например, менеджер загрузки может не проверять подпись стартовой файловой системы, или цепочка проверки компонентов может обрываться после передачи управления программе «init», или ядро может не проверять загружаемые модули), но они устраняемы.
Предзагрузочный контроль целостности – это когда есть компонент, который заранее проверяет целостность всего (реестра Windows, исполняемых файлов, конфигурационных файлов и прочего). Реализуется в составе программы, стартующей до передачи управления менеджеру загрузки (загрузчику) контролируемой операционной системы. Способы реализации: OpROM внутри аппаратного компонента (например, PCI-устройства), плагин к UEFI/BIOS или же измененный образ UEFI/BIOS в составе материнской платы. И тут возникает проблема: как получать данные, целостность которых нужно проверять? В составе Аккорд-АМДЗ (версия на базе DOS) есть собственные парсеры NTFS и реестра Windows. В других подобных продуктах на базе Linux для проверки NTFS может использоваться драйвер ntfs-3g. Кто гарантирует, что данные, «видимые» этими парсерами (драйверами), соответствуют тому, что потом будет «видно» операционной системе? Никто.
Можно, например, перед выключением компьютера изменить одну переменную ядра Windows и все последующие изменения реестра Windows (вплоть до выключения компьютера) не будут записаны в основные файлы реестра, но будут записаны в файлы транзакций. Аккорд-АМДЗ эти модифицированные данные не обнаружит (в процессе следующей загрузки компьютера), ему будут «видны» только те данные, которые были записаны до изменения переменной ядра, потому что в парсере реестра Windows внутри Аккорд-АМДЗ нет поддержки файлов транзакций. Но в ядре Windows такая поддержка есть, а потому ему измененные данные реестра Windows «видны» будут. В итоге, Аккорд-АМДЗ будет «видеть» одно значение ключа реестра Windows (которое будет проходить контроль целостности), а ядро Windows – другое (которое бы не прошло контроль целостности, но по факту прошло, потому что не было «видно» в процессе предзагрузочного контроля целостности).
И подобных штук очень много. Есть разница, как структуры NTFS обрабатываются официальным драйвером NTFS и драйвером ntfs-3g, что позволяет создать файл, который будет иметь некоторое содержимое по версии драйвера ntfs-3g, но который будет пустым по версии официального драйвера NTFS. Это тоже можно использовать для обхода предзагрузочного контроля целостности (например, «обнулив» таким образом исполняемый файл какого-то средства защиты; это требует исполнения вредоносной программы на уровне ядра, но ведь такой сценарий входит в модель угроз).
Почему нельзя использовать официальные драйверы? Во-первых, проблемы с лицензией. Во-вторых, ReactOS поддерживает далеко не все драйверы Windows (драйвер NTFS вроде не поддерживается: But some time in the future, ReactOS will be able to load even native NTFS-drivers). Плюс, реестр Windows реализован не в драйвере, а в самом ядре Windows. То есть предзагрузочный контроль целостности систем с Windows необходимо будет делать на базе Windows. А еще, есть разница в обработке всяких пограничных случаев и в разных версиях ядра Windows. Единственное решение проблемы – отказаться от полного предзагрузочного контроля и сделать что-то на базе Secure Boot. Но это же столько отечественных научных работ по доверенной загрузке нужно признать несостоятельными.
применяют средства доверенной загрузки, в функции которых входит и контроль целостности СЗИ и среды функционирования (ОС), до ее запуска
Предзагрузочный контроль целостности невозможен. Я могу изменить реестр так, что контролирующий компонент изменение не заметит, а ядро ОС – заметит. Я могу создать файл, содержимое которого для контролирующего компонента будет одно, а для драйвера NTFS – файл будет пустым. Потому что нельзя написать код, полностью повторяющий парсинг того, что контролируется.
В этом отчете, похоже, полиморфным называется все, что хоть как-то изменяется:
Nearly all malware and potentially unwanted application (PUA) delivery uses polymorphism—either at the server level, where every executable generated is a unique variant, or the threat itself is polymorphic, making it unique to the recipient.
Собственно, на этом все.
Потому что ее убрали. Потому что ее все равно не использовали.
Таких мест, я думаю, достаточно. Во всяком случае, это доказывает, что по крайней мере один разработчик ReactOS смотрел в утечку кода. И брал оттуда, по крайней мере, одну константу. И ничего вы (как проект) с этим не сделали (посмотрите хотя бы описание коммита, которым убрали эту константу).
Могу еще сказать, что в заголовочных файлах Windows часто раскрываются детали использования конкретных констант или полей (иногда это описание не соответствует действительности), т. е. «просто посмотреть в заголовочный файл» уже достаточно для того, чтобы получить информацию о внутренних деталях реализации.
Тем не менее, действие исключительного права распространяется и на заголовочные файлы. И еще раз: «Developers (devs) have not looked at Microsoft Windows™ source code».
Простите, но: изменение одного параметра != попытка хищения. Как я уже говорил, один признак обычно не является показателем.
Пункт про сбор данных лучше искать в пачке документов, регламентирующих ДБО. Начать можно с договора с банком.
Как в Windows реализован RDP? Программой, конечно же. Чем же еще? Далее читайте определение программы.
В «толстый клиент» можно добавить куда больше «антифрод»-функциональности, чем в «тонкий клиент». Можно даже драйвер загрузить. Вы точно разбираетесь в теме?
А тип действительно не важен, потому что с любым типом клиента можно работать удаленно. Сюрприз, да?
Про «веру» вы точно ничего не писали. Точно умеете читать?
Поздравляю, вы нашли второй признак (первым был факт наличия открытого порта): факт отсутствия открытого порта в прошлом. Попробуйте найти еще возможные признаки.
Никакую. Просто кто-то считает, что одного из «подозрительных» признаков уже достаточно для блокировки со стороны банка. Я же написал, что нет. Перечитайте еще раз.
Речь шла и про тонкие клиенты в том числе. Тут тип клиента роли не играет.
Вы читать умеете? На стороне клиента банка стоит терминальный сервер, где есть клиент системы ДБО. Бухгалтер подключается к этому терминальному серверу и работает. Это не сервер банка, это сервер организации – клиента банка. И с него ведется работа с системой ДБО. Именно так, как вы описали в том же абзаце чуть выше.
И уже из-за наличия таких конфигураций один лишь факт работы на компьютере программы-сервера для удаленного управления (который определяется по открытому порту) не может играть решающей роли.
Более того, «антифрод»-скрипты умеют не только определять открытые порты, но и определять (с некоторой вероятностью, но все же довольно точно), что клиент работает в браузере через RDP/VNC и т. п.
Я работал именно в этом поле, в одной из компаний, которая в обсуждении здесь упоминалась.
В большинстве случаев обнаруженный открытый порт, характерный для программы для удаленного управления компьютером, – это лишь один из признаков, а не немедленная блокировка учетной записи. Еще в том же 2010 году многие организации работали с системами ДБО через терминальный сервер (по RDP).
Кому-то все равно, а кому-то нет. Тем более, есть юридические риски (например, часть 15 статьи 9 ФЗ «О НПС»). Про «еще больший бред» комментировать даже не буду. ;-)
А если кто-то пишет данные с помощью ntfs-3g, то, извините, каждый созданный файл будет иметь весьма кричащий «флаг» «я был записан не с помощью ntfs.sys».
Никак. Защита от умышленного «подкидывания» данных только юридическая – специалист не должен быть заинтересован в исходе дела (в противном случае он подлежит отводу); существует уголовная ответственность за фальсификацию доказательств; специалист несет уголовную ответственность за дачу заведомо ложных показаний; лицо, у которого производится обыск, вправе наблюдать за процессом обыска и за действиями специалиста.
Понятой, если ему это принципиально, может настоять на включении в протокол подробных сведений о том, как копировались данные и (или) как считался от них хеш, а также описания «вилки достоверности» (специалист произвел именно те действия, которые наблюдал понятой, если введенные специалистом команды запускали исполняемые файлы, которые делали именно то, что должны были делать, каких-либо фоновых процессов, затрагивающих искомые данные, не было и т. п.). У понятого, во всяком случае, есть право делать замечания к протоколу, которое не может быть ограничено.
В принципе, если действия с данными производились только из определенного live-дистрибутива, то его носитель можно приобщить к протоколу обыска (например, чтобы подтвердить неизменность программы sha256sum), но на практике такого я не видел. Это, конечно, не исключает тему «закладок» в BIOS/UEFI (которые каким-то образом исказили данные) или тему подмены корневой ФС live-дистрибутива, но все-таки у всего, даже у сомнений, должен быть (и есть) разумный предел.
Это сейчас так принято считать. А вот в статье 60 УПК написано, что понятой удостоверяет, в том числе, содержание следственного действия. Таким образом, понятой должен понимать, что делает специалист (иначе содержание следственного действия ему, понятому, не понятно).
Жаль, что вам не видно разницы. Потому что она есть, да еще и принципиальная. Сравните, как работают АМДЗ и реализации доверенной загрузки на базе Secure Boot (желательно еще с TPM и обеспечением целостности файловой системы через ее шифрование).
Secure Boot не будет пытаться что-то сделать с реестром Windows из UEFI. АМДЗ – будет, потому что ни менеджер загрузки, ни ядро не предоставляют интерфейс для контроля целостности на тех этапах, где это нужно.
Еще раз. Для Secure Boot не нужно иметь UEFI-драйвер для NTFS и реестра Windows. Для АМДЗ – нужно (если, конечно, не убирать поддержку Windows вообще, хотя и это оставляет необходимость поддерживать, например, FAT и Ext2/3/4).
Использование сторонних парсеров (драйверов) порождает атаки, которых в принципе нет в реализациях Secure Boot. Что, конечно, не исключает иных видов атак.
Очень хорошо, если у вас такое реализовано. Только вот ExitBootServices вызывается до загрузки некоторых критичных кустов реестра Windows. То есть ваш весьма сомнительный с точки зрения реализации способ уже не защищает от того, от чего должен защищать.
И еще. Код для работы с реестром в менеджере загрузки и в ядре тоже немного отличается. Например, в порядке применения журналов транзакций. Нельзя применять одно для контроля целостности того, что использует другое.
Вот, например, нужный раздел из моей спецификации к формату файлов реестра.
Куда разумнее подгружать библиотеку offreg (отлично работает под Wine), проводить контроль целостности с ее помощью, а затем сохранять куст в исходный файл (таким образом, все, что оказалось невидимым для offreg, останется невидимым и для контролируемой операционной системы). Только вот библиотеки offntfs нет.
Очень хорошо, что умеете. Тут уже возникают вопросы по поводу того, когда стартует гипервизор, можно ли его убрать теми атаками, про которые я веду речь, или нет.
Не на вектор, а на конкретный недостаток. От вектора атаки предзагрузочный контроль целостности не защищает, хотя и можно обрабатывать конкретные пограничные случаи. Вот только есть ли у вас их список?
Умеет. Берите отладочные символы и вперед: HvpApplyIncrementalLogFile, HvpApplyLegacyLogFile, HvAnalyzeLogFiles.
Смотрите выше, ибо умеет. Отсутствие поддержки транзакций до ядра – это, простите, Windows 2000. В Windows XP уже поддержка есть и никуда не исчезала.
В чью-то модель угроз? Если так, то это проблемы того, кто модель угроз писал. АМДЗ не нужен в таком случае вообще, достаточно драйвера для контроля целостности.
Я не вижу смысла продолжать этот разговор. Я указал на вполне конкретные недостатки, описал общий вектор атаки, в который эти недостатки укладываются, а в ответ узнал лишь то, что winload вы не «реверсили», а потому, согласно вашему заблуждению, предложенные мной атаки не работают.
Я так не считаю. Я лишь утверждаю, что поэтапный контроль лучше. Потому что целостность следующего компонента будет проверяться текущим компонентом (им или с его участием, если говорить точнее), а не каким-то сторонним компонентом, который может прочитать что-то не так, как надо.
Что, разумеется, не исключает существование каких-то уязвимостей и недостатков. Но в случае с АМДЗ проблема носит принципиальный характер.
Ядро, стартовую файловую систему, реестр Windows, модули ядра (драйверы), пользовательское окружение тоже модуль доверенной загрузки загружает? Нет. Модуль доверенной загрузки действительно передает управление загрузчику, который этот модуль и прочитал в память. А вот куст реестра SYSTEM модуль доверенной загрузки для ядра (или winload) не загружает.
То есть, сначала предзагрузочный компонент проверяет целостность некоторых частей реестра Windows (с использованием собственного парсера), затем передается управление менеджеру загрузки Windows, а потом, немного позднее, стартует ваш драйвер, который может проверить целостность того, что было проверено раньше, но уже с использованием функций ядра.
А теперь подумайте, что будет, если проверка целостности реестра на предзагрузочном этапе (до передачи управления менеджеру загрузки) пройдет успешно, но ваш драйвер будет вырезан (или заменен на «заглушку», если есть сторожевой модуль) из соответствующего куста реестра Windows (и предзагрузочный компонент этого не заметит, потому что смотрите выше). Собственно, приехали.
Нет, не понимаю. Версии могут быть разными. Если вы «на лету» берете драйверы из стартовой файловой системы (а для этого нужно, как минимум, смонтировать /boot/), то да, драйверы будут теми же (при этом возникает вопрос, как таким драйверам доверять, но это уже можно решить).
Непаханое поле, пока что.
Атакующий может целиться и не в защищаемые данные. Так что «цена данных» и «цена преодоления защиты» – это отстраненные понятия.
Если вы делаете так, то тут могут появиться и другие особенности (помимо разницы в работе парсеров и драйверов). Если, например, дистрибутив использует dracut, то я могу после контроля целостности оборудования подключить USB-накопитель и до окончания загрузки заменить оригинальное ядро (целостность которого была проверена) на свое (разумеется, при условии, что отладочная оболочка отключена и рутовый шелл в initramfs при сбое не получить). Но это уже другая история.
Предзагрузочный контроль целостности – это когда есть компонент, который заранее проверяет целостность всего (реестра Windows, исполняемых файлов, конфигурационных файлов и прочего). Реализуется в составе программы, стартующей до передачи управления менеджеру загрузки (загрузчику) контролируемой операционной системы. Способы реализации: OpROM внутри аппаратного компонента (например, PCI-устройства), плагин к UEFI/BIOS или же измененный образ UEFI/BIOS в составе материнской платы. И тут возникает проблема: как получать данные, целостность которых нужно проверять? В составе Аккорд-АМДЗ (версия на базе DOS) есть собственные парсеры NTFS и реестра Windows. В других подобных продуктах на базе Linux для проверки NTFS может использоваться драйвер ntfs-3g. Кто гарантирует, что данные, «видимые» этими парсерами (драйверами), соответствуют тому, что потом будет «видно» операционной системе? Никто.
Можно, например, перед выключением компьютера изменить одну переменную ядра Windows и все последующие изменения реестра Windows (вплоть до выключения компьютера) не будут записаны в основные файлы реестра, но будут записаны в файлы транзакций. Аккорд-АМДЗ эти модифицированные данные не обнаружит (в процессе следующей загрузки компьютера), ему будут «видны» только те данные, которые были записаны до изменения переменной ядра, потому что в парсере реестра Windows внутри Аккорд-АМДЗ нет поддержки файлов транзакций. Но в ядре Windows такая поддержка есть, а потому ему измененные данные реестра Windows «видны» будут. В итоге, Аккорд-АМДЗ будет «видеть» одно значение ключа реестра Windows (которое будет проходить контроль целостности), а ядро Windows – другое (которое бы не прошло контроль целостности, но по факту прошло, потому что не было «видно» в процессе предзагрузочного контроля целостности).
И подобных штук очень много. Есть разница, как структуры NTFS обрабатываются официальным драйвером NTFS и драйвером ntfs-3g, что позволяет создать файл, который будет иметь некоторое содержимое по версии драйвера ntfs-3g, но который будет пустым по версии официального драйвера NTFS. Это тоже можно использовать для обхода предзагрузочного контроля целостности (например, «обнулив» таким образом исполняемый файл какого-то средства защиты; это требует исполнения вредоносной программы на уровне ядра, но ведь такой сценарий входит в модель угроз).
Почему нельзя использовать официальные драйверы? Во-первых, проблемы с лицензией. Во-вторых, ReactOS поддерживает далеко не все драйверы Windows (драйвер NTFS вроде не поддерживается: But some time in the future, ReactOS will be able to load even native NTFS-drivers). Плюс, реестр Windows реализован не в драйвере, а в самом ядре Windows. То есть предзагрузочный контроль целостности систем с Windows необходимо будет делать на базе Windows. А еще, есть разница в обработке всяких пограничных случаев и в разных версиях ядра Windows. Единственное решение проблемы – отказаться от полного предзагрузочного контроля и сделать что-то на базе Secure Boot. Но это же столько отечественных научных работ по доверенной загрузке нужно признать несостоятельными.
Предзагрузочный контроль целостности невозможен. Я могу изменить реестр так, что контролирующий компонент изменение не заметит, а ядро ОС – заметит. Я могу создать файл, содержимое которого для контролирующего компонента будет одно, а для драйвера NTFS – файл будет пустым. Потому что нельзя написать код, полностью повторяющий парсинг того, что контролируется.
При наличии прав администратора – отключается (есть способы). Такой обход за уязвимость производители не считают.
Об этом в Интернете было написано еще в 2016 году. Ну и на ZeroNights я рассказывал как раз про случай с KRD. ;-)
Есть похожая атака, которая, однако, не требует драйвера. Достаточно прав администратора.
Ага, а еще чуть ли не каждый ИБ-вендор производит что-то «следующего поколения».