Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
Ожидаемо.
про пароли пользователей совпадающие это у вас не вызывает диссонанса? нет? вы можете просто залогиниться под админом, если его пароль такой же как у вашего «простого» юзера, зачем сюда приплетать нашу защиту? я же про это вам говорил уже…
и сразу видно по статье, что на новой версии (ей больше месяца) вы ничего не проверяли.
и «сотрудничество», как вы его называете заключалось бы в фактическом оплате вашего шантажа — вы предлагали не публиковать статью за деньги. поэтому говорить то собственно было и не о чем…
повторюсь, что гарантированная защита от админа в винде невозможна. можно лишь немного усложнить жизнь.
и «сотрудничество», как вы его называете заключалось бы в фактическом оплате вашего шантажа — вы предлагали не публиковать статью за деньги. поэтому говорить то собственно было и не о чем…
повторюсь, что гарантированная защита от админа в винде невозможна. можно лишь немного усложнить жизнь.
Есть подозрение, что загрузка вредоносного драйвера раньше, чем загрузится драйвер защитного средства — не «немного усложнить жизнь»
Ну допустим антивирь параллельно работает, но вот валиться из-за левой библиотечки — это ни в какие ворота.
Нас так не учили в институте ошибки обрабатывать.
Нас так не учили в институте ошибки обрабатывать.
Понятно что это косяк. Но, как я понял, разработчик этой софтины утверждает, будто админ может сломать все что угодно и жизнь ему при этом можно лишь «немного усложнить». Я же высказываю подозрения, что можно не «немного»
Они это утверждают только здесь, среди проф аудитории.
На рекламных семинарах в СофтЛайне, к примеру, про такие интимные подробности ни слова!
В качестве примера смотрите самозащиту Каспера и ДрВеба.
На рекламных семинарах в СофтЛайне, к примеру, про такие интимные подробности ни слова!
В качестве примера смотрите самозащиту Каспера и ДрВеба.
О самозащите Dr.Web я знаю не по наслышке. Я видел как нас выносили трои на раз, видел как все это дорабатывалось, доделывалось, ломалось и так далее. Потому и сомневаюсь что админ так уж всемогущ :-)
В качестве примера смотрите самозащиту Каспера и ДрВеба.
При наличии прав администратора – отключается (есть способы). Такой обход за уязвимость производители не считают.
Ессно есть.
Даже тулзы специальные разработаны самими производителями.
Но вот так вот, что мышкой тыкнуть пару раз, такого нет.
Даже тулзы специальные разработаны самими производителями.
Но вот так вот, что мышкой тыкнуть пару раз, такого нет.
Прошу прощения, но если Ваш нарушитель может тыкнуть мышкой и удалить часть системных файлов СЗИ, что ему мешает тыкнуть в иконку «специальной тулзы производителя»? Или я неправильно понял вектор атаки?
Не «часть системных файлов СЗИ», а «часть системных файлов ОС»
Саму СЗИ они таки смогли защитить, а файлы Винды нет, понадеявшись на мощь синего экрана.
Плюс ко всему забыли про возможность менять системный шелл, а это за гранью, ИМХО.
Специальная тулза как минимум просит капчу, т.е. есть намек на защиту от ботов.
Саму СЗИ они таки смогли защитить, а файлы Винды нет, понадеявшись на мощь синего экрана.
Плюс ко всему забыли про возможность менять системный шелл, а это за гранью, ИМХО.
Специальная тулза как минимум просит капчу, т.е. есть намек на защиту от ботов.
Нормальная самозащита софта от другого софта, работающего на том же уровне привилегий на текущей x86 архитектуре принципиально невозможна. Т.е. защитить драйвер от драйвера, гипервизор от гипервизора и т.д. нельзя. Можно только осложнить взлом. Вкладывать ресурсы в такую защиту имеет смысл только если вы рассчитываете на НЕ-целевые атаки (антивирус общего назначения).
Повредить файлик можно и с пользовательского режима умудриться или сбой в файловой системе произойдет.
Нормальная реакция — блокировка всего и смс администратору, а не полностью открытое состояние.
Особенно прикольно, что драйвера то остаются работать, контроль над системой сохранить легко.
Но почему-то все завязано на странную службу.
Нормальная реакция — блокировка всего и смс администратору, а не полностью открытое состояние.
Особенно прикольно, что драйвера то остаются работать, контроль над системой сохранить легко.
Но почему-то все завязано на странную службу.
Вы абсолютно правы, что возможны «случайные» модификации файлов, поэтому в нормальных защищенных системах до сих пор применяют средства доверенной загрузки, в функции которых входит и контроль целостности СЗИ и среды функционирования (ОС), до ее запуска.
Блокировка — нормальная реакция системы защиты на факт НСД. Но если система защиты отключена (по какой-то причине), то она не может ничего заблокировать.
P/S: Я никоим образом не защищаю конкретную систему, и вполне допускаю, что она «отстой». Просто статья довольно сумбурная и было бы неплохо ввести в нее дополнительные уточнения по модели угроз, тому как она соответствует предлагаемым векторам атак и т.д.
Блокировка — нормальная реакция системы защиты на факт НСД. Но если система защиты отключена (по какой-то причине), то она не может ничего заблокировать.
P/S: Я никоим образом не защищаю конкретную систему, и вполне допускаю, что она «отстой». Просто статья довольно сумбурная и было бы неплохо ввести в нее дополнительные уточнения по модели угроз, тому как она соответствует предлагаемым векторам атак и т.д.
Почитайте предыдущую статью, чтоб не повторяться.
Тут проблема в архитектуре.
Как обычно программная СЗИ состоит из драйвера(ов) и службы.
Валится служба, драйверы остаются.
Казалось бы есть все условия для сохранения уровня защищенности, но нет.
Я специально не акцентирую внимание на загрузку с альтернативного носителя, ибо ни одна чисто программная СЗИ с этим не справится.
Допустим, что БИОС запаролен, комп опечатан и с УСБ не загрузишься.
АПМДЗ не проходит ибо по цене будет космос.
Тут проблема в архитектуре.
Как обычно программная СЗИ состоит из драйвера(ов) и службы.
Валится служба, драйверы остаются.
Казалось бы есть все условия для сохранения уровня защищенности, но нет.
Я специально не акцентирую внимание на загрузку с альтернативного носителя, ибо ни одна чисто программная СЗИ с этим не справится.
Допустим, что БИОС запаролен, комп опечатан и с УСБ не загрузишься.
АПМДЗ не проходит ибо по цене будет космос.
от антивируса вы тоже считаете, что когда валится служба а драйвер остается полного сохранения уровня защищенности? HIPS/OAS в драйвере ага конечно.
Хотя были конечно веселые прецеденты(symantec) отгребания bsod/kexec через битый архив.
Хотя были конечно веселые прецеденты(symantec) отгребания bsod/kexec через битый архив.
Ожидаю адекватного поведения.
Обычно драйвер что-то блокирует, служба управляет, т.е. дает команды на разблокировку, к примеру, УСБ-накопителя.
Если службу уронить, то блокировки продолжат работать, информация останется защищена.
Тут же все точно наоборот.
Еще в прошлой статье указывал на 2 архитектурные проблемы продукта, которые разработчик устранять не собирается.
1. Изначально неверный подход к установке блокировок.
По умолчанию должно быть ЗАКРЫТО, а только после проверки блокировки должны сниматься.
2. Неправильно написанная служба. По правилам из МСДН на голом С пишется каркас службы с обработчиками ServiceStart ServiceStop и т.п., весь остальной функционал на MFC или дотНет подгружается динамически. В данном случае это полностью исключает возможность повалить службу удаляя второстепенные файлы.
По ощущениям кто-то в 90х написал тестик для диплома или УИРа, а потом вокруг него коммерческий продукт, и так все лень перепсать по нормальному.
Обычно драйвер что-то блокирует, служба управляет, т.е. дает команды на разблокировку, к примеру, УСБ-накопителя.
Если службу уронить, то блокировки продолжат работать, информация останется защищена.
Тут же все точно наоборот.
Еще в прошлой статье указывал на 2 архитектурные проблемы продукта, которые разработчик устранять не собирается.
1. Изначально неверный подход к установке блокировок.
По умолчанию должно быть ЗАКРЫТО, а только после проверки блокировки должны сниматься.
2. Неправильно написанная служба. По правилам из МСДН на голом С пишется каркас службы с обработчиками ServiceStart ServiceStop и т.п., весь остальной функционал на MFC или дотНет подгружается динамически. В данном случае это полностью исключает возможность повалить службу удаляя второстепенные файлы.
По ощущениям кто-то в 90х написал тестик для диплома или УИРа, а потом вокруг него коммерческий продукт, и так все лень перепсать по нормальному.
применяют средства доверенной загрузки, в функции которых входит и контроль целостности СЗИ и среды функционирования (ОС), до ее запуска
Предзагрузочный контроль целостности невозможен. Я могу изменить реестр так, что контролирующий компонент изменение не заметит, а ядро ОС – заметит. Я могу создать файл, содержимое которого для контролирующего компонента будет одно, а для драйвера NTFS – файл будет пустым. Потому что нельзя написать код, полностью повторяющий парсинг того, что контролируется.
Извините, не совсем понял, могли бы пояснить? До запуска основной ОС можно контролировать целостность из модуля UEFI (Secure Boot?), из аппаратного модуля с Option ROM, из загрузчика, лежащего на аппаратно-ридонли флешке, установленной внутри корпуса и т.д. Если рассматривать возможность вскрытия корпуса, то, конечно, защита возможна только относительная (корневой ключ, зашитый в проц на производстве и надежда, что Китайцы не смогут выпустить свой процессор, но с другим ключем).
Я не очень понимаю, почему нельзя написать код, который будет повторять парсинг того, что контролируется? Я могу просто воспользоваться тем же драйвером, что и винда :) РеактОС вон грузит виндовые драйвера, что мешает то же самое сделать в контролирующем компоненте?
Я не очень понимаю, почему нельзя написать код, который будет повторять парсинг того, что контролируется? Я могу просто воспользоваться тем же драйвером, что и винда :) РеактОС вон грузит виндовые драйвера, что мешает то же самое сделать в контролирующем компоненте?
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. Но это же столько отечественных научных работ по доверенной загрузке нужно признать несостоятельными.
Предзагрузочный контроль целостности – это когда есть компонент, который заранее проверяет целостность всего (реестра 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. Но это же столько отечественных научных работ по доверенной загрузке нужно признать несостоятельными.
1. В итоге, ваше утверждение
2. Не вижу никакой разницы между Secure Boot и нормально реализованным КЦ в АПМДЗ, за исключением обозначенной выше проблемы вскрытия корпуса, которая в нормальных системах исключается другими мерами. И то и другое — модули UEFI, работающие в один и тот же момент времени. Почему вы считаете, что в модуле Secure Boot не может быть уязвимостей, а в таком же модуле UEFI, загружающемся из Option ROM обязательно будут? На всякий случай уточню, что АПМДЗ точно также может проверять целостность загрузчика уже после загрузки в память.
3. Я не могу отвечать за все СЗИ под Windows на Российском рынке, но то, что я разрабатываю, работает больше похоже на Secure Boot: наш АПМДЗ контролирует целостность загрузчика, ядра и веток реестра, которые парсит загрузчик, а потом стартует наш бутовый драйвер, который контролирует целостность остального уже с использованием виндовых драйверов/функций ядра.
На всякий случай уточню, что изначально реестр винды грузит и парсит winload, а не ядро, вычитывая оттуда список бутовых драйверов, к которым относятся и все средства защиты.
4. Большая часть разрабатываемых и внедряемых на текущий момент систем в гос-секторе (где и применяются сертифицированные СЗИ), делаются на Linux'ах, так как Майкрософту запретили продавать винды во многие наши госы. В этом случае АПМДЗ контролирует целостность ядра и initramfs (в котором СЗИ реализовано в виде LSM-модуля), а потом делает в него kexec, без всяких загрузчиков. Драйвера файловых систем в АПМДЗ и целевом Linux'е, как вы понимаете, одинаковые.
5. Все системы под максимальную модель нарушителя теперь строятся только на верифицируемой (читай отечественной) элементной базе, т.е. на базе интеловских процов с ME, ISH и другими плюшками, можно построить только систему под внутреннего нарушителя с моделью из КС3 (читай «тупой и ленивый нарушитель»). А на Эльбрусьях, например, вместо Secure Boot есть наш АПМДЗ, который грузит Linux kexec'ом.
6. Не бывает абсолютной защиты. Бывает защита, пробивание которой стоит дороже, чем данные, которые она защищает.
Если отличий в реализации парсера реестра / драйвера NTFS в АПМДЗ и winload'е будет мало, а их поиск будет слишком дорогим, то проще будет выбрать другой вектор атаки. В конце концов, там после АПМДЗ еще и целиковая винда будет работать. Где проще найти/спрятать уязвимость, в АПМДЗ или в ядре винды?
7.
Прошу прощения, но звучит как будто все кто занимается разработкой отечественных систем защиты — тупые, а один вы Дартаньян :) Все понимают, что у АПМДЗ есть минусы, но пока у нас в стране нет своей элементной базы с собственным Secure Boot'ом и поэтессами, ничего лучше пока никто не предложил.
Предзагрузочный контроль целостности невозможен.сводится к банальной проблеме останова, теореме Райса и т.д. Т.е. вы апелируете к тому, что в конкретных реализациях (ntfs-3g vs ntfs.sys) есть разница в реализации (в любом нетривиальном коде наверняка есть хотя бы одна ошибка).
2. Не вижу никакой разницы между Secure Boot и нормально реализованным КЦ в АПМДЗ, за исключением обозначенной выше проблемы вскрытия корпуса, которая в нормальных системах исключается другими мерами. И то и другое — модули UEFI, работающие в один и тот же момент времени. Почему вы считаете, что в модуле Secure Boot не может быть уязвимостей, а в таком же модуле UEFI, загружающемся из Option ROM обязательно будут? На всякий случай уточню, что АПМДЗ точно также может проверять целостность загрузчика уже после загрузки в память.
3. Я не могу отвечать за все СЗИ под Windows на Российском рынке, но то, что я разрабатываю, работает больше похоже на Secure Boot: наш АПМДЗ контролирует целостность загрузчика, ядра и веток реестра, которые парсит загрузчик, а потом стартует наш бутовый драйвер, который контролирует целостность остального уже с использованием виндовых драйверов/функций ядра.
На всякий случай уточню, что изначально реестр винды грузит и парсит winload, а не ядро, вычитывая оттуда список бутовых драйверов, к которым относятся и все средства защиты.
4. Большая часть разрабатываемых и внедряемых на текущий момент систем в гос-секторе (где и применяются сертифицированные СЗИ), делаются на Linux'ах, так как Майкрософту запретили продавать винды во многие наши госы. В этом случае АПМДЗ контролирует целостность ядра и initramfs (в котором СЗИ реализовано в виде LSM-модуля), а потом делает в него kexec, без всяких загрузчиков. Драйвера файловых систем в АПМДЗ и целевом Linux'е, как вы понимаете, одинаковые.
5. Все системы под максимальную модель нарушителя теперь строятся только на верифицируемой (читай отечественной) элементной базе, т.е. на базе интеловских процов с ME, ISH и другими плюшками, можно построить только систему под внутреннего нарушителя с моделью из КС3 (читай «тупой и ленивый нарушитель»). А на Эльбрусьях, например, вместо Secure Boot есть наш АПМДЗ, который грузит Linux kexec'ом.
6. Не бывает абсолютной защиты. Бывает защита, пробивание которой стоит дороже, чем данные, которые она защищает.
Если отличий в реализации парсера реестра / драйвера NTFS в АПМДЗ и winload'е будет мало, а их поиск будет слишком дорогим, то проще будет выбрать другой вектор атаки. В конце концов, там после АПМДЗ еще и целиковая винда будет работать. Где проще найти/спрятать уязвимость, в АПМДЗ или в ядре винды?
7.
Но это же столько отечественных научных работ по доверенной загрузке нужно признать несостоятельными.
Прошу прощения, но звучит как будто все кто занимается разработкой отечественных систем защиты — тупые, а один вы Дартаньян :) Все понимают, что у АПМДЗ есть минусы, но пока у нас в стране нет своей элементной базы с собственным Secure Boot'ом и поэтессами, ничего лучше пока никто не предложил.
Почему вы считаете, что в модуле 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 при сбое не получить). Но это уже другая история.
Я лишь утверждаю, что поэтапный контроль лучше.
АПМДЗ является частым случаем реализации одной из стадий поэтапного контроля. Это такой же кусок кода, как и сам winload. Они одновременно находятся в одной и той же памяти и исполняются одновременно на одном уровне привелегий. От того, что вы расположите их в одном PE или в разных ничего не поменяется.
Еще раз повторю: вы говорите о различиях в реализации парсинга в winload'е и АПМДЗ, что является частным случаем ошибки/уязвимости. Точно такие же ошибки есть в любом коде, будь то Secure Boot или любая другая система защиты.
Есть множество статей о реальных уязвимостях в конкретных реализациях Secure Boot'а.
Ничего не мешает АПМДЗ проверять целостность реестра и наличие драйвера СЗИ уже в памяти по ExitBootServices. Можно использовать для проверки реестра в памяти куски кода winload'а, вызывая их из своего UEFI-модуля. Можно исполнять все, вплоть до получения управления драйвером в тонком гипервизоре (blue pill/bitvisor) и контролировать целостность всех исполняемых страниц памяти при их вызове (ага, мы так умеем). Можно написать свой загрузчик винды, который будет использовать тот же код (ReactOS'овский XP грузил на ура). На любой названный вами вектор атаки я всегда смогу ответить методом защиты. Это обычное соревнование брони и снаряда. Вы будете усложнять потенциальные атаки, а я защиту, а остановится это там, где разработка методов атаки станет слишком дорогой.
Также учтите, что ФСБ, например, выдает заключение на винду только в составе с конкретным СЗИ. Т.е. рассматривается всегда комплекс: АПМДЗ, СЗИ, среда функционирования (ОС + Железо).
Если вдруг Вы хотите ответ по конкретным предложенным атакам, хотя это ничего и не доказывает, то вот:
winload не умеет в файлы транзакций, так что ничем не отличается даже от аккорда. Незакрытые транзации закроет уже ядро, а все бутовые драйвера, загруженные winload'ом, получат управление.
В модель угроз не входит возможность исполнить код в ядре, а без этого вы NTFS не поломаете. Ни одно СЗИ на (не только Российское) не сможет защититься от кода на том же уровне привелегий. Для систем выше КС3 требуется обеспечение замкнутости программной среды, т.е. СЗИ проверяет ВЕСЬ исполняемый в системе код, а не только код, исполняемый в ядре. КС3 и ниже — тупой ленивый нарушитель. Уязвимости (и в ядре и в юзер моде) рассматриваются как нечто обязательно присутствующее и, согласно современным требованиям, любые СЗИ + ОС обязаны реализовывать меры по снижению вероятности эксплуатации: CFG, ASLR и т.д. Все понимают, что абсолютной защиты небывает.
Я не знаю ниодного сертифицированного дистрибутива с СЗИ, использующего dracut. Но если есть опубликованная уязвимость или документированная возможность, позволяющая «на лету заменить ядро», при сертификации это бы закрыли.
Ничего не забыл? Т.е. ни одна из предложенных вами атак в реальной жизни не сработает. Это вовсе не означает, что вы не сможете найти уязвимость.
АПМДЗ является частым случаем реализации одной из стадий поэтапного контроля. Это такой же кусок кода, как и сам 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 вы не «реверсили», а потому, согласно вашему заблуждению, предложенные мной атаки не работают.
winload.efi
1. В итоге я все еще уверен, что утверждение
является сильным преувеличением.
Если бы Вы сказали «Предзагрузочный контроль целостности пораждает ряд векторов атак, которых нет в Secure Boot», это было бы гораздо ближе к правде.
Очень хорошо, что Вы про них знаете. Но я не вижу принципиальных сложностьей в борьбе с ними.
2. Я Вам верю, что ошибся, так как действительно лично не изучал как работает winload с реестром, а воспользовался информацией полученной от коллег. Большое спасибо, что Вы изучили и об этом рассказали. Тем не менее, даже учитывая, что winload работает с логом транзакций, я не вижу принципиальной сложности в реализации. Если сложно транзакции имплементировать можно просто удалять лог для проверяемых веток или помечать ветку чистой (поправив sequence + чексумму). Запись в них в нормальной работе СЗИ произвоится все равно не должна.
3. В моем понимани, единственное что должен гарантировать АПМДЗ с точки зрения контроля целостности — это то, что СЗИ работающее в Windows получит управление. Я уже указал, что для СЗИ под Windows сейчас работает подход с виртуализацией, а для Linux СЗИ встроенно в ядро, поэтому достаточно контролировать его и initramfs перед kexec'ом.
4. Актуальней будет, если вы укажете на разницу при использовании Linux. До этого вы писали про разные версии драйверов/ядер, а я не понял к чему это, так как АПМДЗ контролирует только то, что грузит в память, во время kexec -l, т.е. ядро и initramfs. В моем понимании это никак не отличается от Secure Boot.
5. Какой вы можете предложить альтернативный путь? Переписать винду/отказаться от винды? Так этим путем и идет наше государство, пересаживаясь на Linux.
6. Если Вы этот разговор закончили, хотел бы сказать большое спасибо, было позновательно и интересно. Побольше бы таких осведомленных комментаторов.
Предзагрузочный контроль целостности невозможен.
является сильным преувеличением.
Если бы Вы сказали «Предзагрузочный контроль целостности пораждает ряд векторов атак, которых нет в Secure Boot», это было бы гораздо ближе к правде.
Очень хорошо, что Вы про них знаете. Но я не вижу принципиальных сложностьей в борьбе с ними.
2. Я Вам верю, что ошибся, так как действительно лично не изучал как работает winload с реестром, а воспользовался информацией полученной от коллег. Большое спасибо, что Вы изучили и об этом рассказали. Тем не менее, даже учитывая, что winload работает с логом транзакций, я не вижу принципиальной сложности в реализации. Если сложно транзакции имплементировать можно просто удалять лог для проверяемых веток или помечать ветку чистой (поправив sequence + чексумму). Запись в них в нормальной работе СЗИ произвоится все равно не должна.
3. В моем понимани, единственное что должен гарантировать АПМДЗ с точки зрения контроля целостности — это то, что СЗИ работающее в Windows получит управление. Я уже указал, что для СЗИ под Windows сейчас работает подход с виртуализацией, а для Linux СЗИ встроенно в ядро, поэтому достаточно контролировать его и initramfs перед kexec'ом.
4. Актуальней будет, если вы укажете на разницу при использовании Linux. До этого вы писали про разные версии драйверов/ядер, а я не понял к чему это, так как АПМДЗ контролирует только то, что грузит в память, во время kexec -l, т.е. ядро и initramfs. В моем понимании это никак не отличается от Secure Boot.
5. Какой вы можете предложить альтернативный путь? Переписать винду/отказаться от винды? Так этим путем и идет наше государство, пересаживаясь на Linux.
6. Если Вы этот разговор закончили, хотел бы сказать большое спасибо, было позновательно и интересно. Побольше бы таких осведомленных комментаторов.
Интересно было почитать про АПМДЗ, т.к. по работе мы с ними не пересекаемся. Даже сквозной логин из замка в ОС регуляторы запрещают.
Применительно к рассматриваемому продукту применение АПМДЗ клиентами не рассматривается из-за цены.
Применительно к рассматриваемому продукту применение АПМДЗ клиентами не рассматривается из-за цены.
Надо будет написать статью про современные АПМДЗ как-нибудь, а то много заблуждений основанных на опыте общения со старинными DOS'овыми железками бытует :)
Странные у вас регуляторы. У нас в рамках всех СЗИ (и Win и Linux) есть Authentication Package и PAM-модули для SSO и даже релогина замковых пользователей, включая удаленную аутентификацию, смену аутентифицирующей информации и т.д.
Про цену — это абсолютно верно. Аппаратные замки оправданы только начиная с класса КС3, а таких систем не так уж и много.
Странные у вас регуляторы. У нас в рамках всех СЗИ (и Win и Linux) есть Authentication Package и PAM-модули для SSO и даже релогина замковых пользователей, включая удаленную аутентификацию, смену аутентифицирующей информации и т.д.
Про цену — это абсолютно верно. Аппаратные замки оправданы только начиная с класса КС3, а таких систем не так уж и много.
Кстати, я уже пользовался вашим yarp'ом и не узнал в Вас автора. Полезная тулза :)
Ничего не забыл? Т.е. ни одна из предложенных вами атак в реальной жизни не сработает. Это вовсе не означает, что вы не сможете найти уязвимость.
Тихо и незаметно исправлены две уязвимости в загрузчике ядра Windows (winload.exe/winload.efi), которые позволяют сделать то, что было описано мной (в отношении одного малоизвестного, но все же важного компонента Windows).
Для контроля целостности с использованием TPM загрузчик ядра считает хеш от некоторых данных, затем эти же данные (без изменений) передаются ядру, которое начинает их использовать, но, внезапно, оказывается, что хеш подсчитан не тот, потому что два парсера (в загрузчике ядра и в ядре соответственно) «видят» разные данные в одном и том же буфере. В итоге значения PCR ожидаемые, а используемые данные — другие (не соответствующие хешу).
Описание тут.
Именно поэтому кто первый встал — того и тапки, то есть загружать драйвер надо как можно раньше и препятствовать попыткам других драйверов вынести хороший. Приведенные выше примеры так умеют
Могу выложить переписку.
Предлагал решить архитектурные проблемы, ибо опыт имею 20 летний именно в этом вопросе.
Функционал DLP в разрабатываемой с моим участием системе был лишь одним маленьким винтиком.
С паролями такого не должно быть, потому что не должно быть никогда!
При сертификации есть 30 лет назад разработанные методики проверки и это бы нашлось.
но вы же выше этого, сертификация — не царское дело.
Офицер может напутать листки с паролями при раздаче.
Предлагал решить архитектурные проблемы, ибо опыт имею 20 летний именно в этом вопросе.
Функционал DLP в разрабатываемой с моим участием системе был лишь одним маленьким винтиком.
С паролями такого не должно быть, потому что не должно быть никогда!
При сертификации есть 30 лет назад разработанные методики проверки и это бы нашлось.
но вы же выше этого, сертификация — не царское дело.
Офицер может напутать листки с паролями при раздаче.
Сколько же крови мне попил этот «великий» продукт мирового уровня во время работы в поддержке. Но у СБ все хорошо — это Windows кривая.
Вообще не понятно в рамках какой модели угроз проводилось тестирование. Если считать админа нарушителем, то что ему мешает загрузиться с флешки, открутить нафиг DLP из реестра и радоваться жизни?
В заключении на СЗИ (а, судя по сайту, на эту штуку есть сертификат ФСТЭК), всегда есть ограничительная часть, в которой указано от чего оно защищает. Если вы выходите за рамки этой ограничительной части, то ваши тесты ни о чем не говорят.
В заключении на СЗИ (а, судя по сайту, на эту штуку есть сертификат ФСТЭК), всегда есть ограничительная часть, в которой указано от чего оно защищает. Если вы выходите за рамки этой ограничительной части, то ваши тесты ни о чем не говорят.
там тестирование уровня Бог. пока я намеками не выяснил, что у админа и простого юзера совпадают пароли, мне предлагалось «купить» эту уязвимость. и до сих пор автор продолжает настаивать, что это нормально, когда пароли совпадают…
Именно так системы и тестируют.
И все это ловится на виртуалках либо стенде.
Про ФСТЭК уже обсуждалось — единственный простенький профиль на работу со сменными носителями.
Никаких РД АС по серьезным уровням и близко нет.
И все это ловится на виртуалках либо стенде.
Про ФСТЭК уже обсуждалось — единственный простенький профиль на работу со сменными носителями.
Никаких РД АС по серьезным уровням и близко нет.
Я, например, не знал, что «про ФСТЭК уже обсуждалось», а в статье этого не увидел.
Вы говорите правильные вещи, которые надо было указать в статье, чтобы она собрала плюсов:
— на что сертифицировано данное изделие
— модель угроз со ссылкой на правила пользования изделием
— методики тестирования с описанием вашего стенда
— ваши предложения по улучшению данной системы и т.д.
Если сделать статью более системной, отношение к ней может измениться как у читателей, так и у производителя.
На мой взгляд, на текущий момент и статья и реакция производителя слишком эмоциональны, что в таких вопросах явно лишнее.
Вы говорите правильные вещи, которые надо было указать в статье, чтобы она собрала плюсов:
— на что сертифицировано данное изделие
— модель угроз со ссылкой на правила пользования изделием
— методики тестирования с описанием вашего стенда
— ваши предложения по улучшению данной системы и т.д.
Если сделать статью более системной, отношение к ней может измениться как у читателей, так и у производителя.
На мой взгляд, на текущий момент и статья и реакция производителя слишком эмоциональны, что в таких вопросах явно лишнее.
Аппаратуру не рассматривал, ибо и так все ясно.
Собсно вусе в виртуалке крутилось.
Собсно вусе в виртуалке крутилось.
На предложение сотрудничества по устранению обнаруженного руководство СмартЛайн отреагировало вяло, что еще больше удивляет.
Виталий, а что Вас собственно удивляет? давайте я напомню тем, кто не в теме, как Вы поступили в первый раз (с первой статьей)?
Вы пришли к нам, сказав, что обнаружили два бага в самозащите и попросили денег. Bug bounty это нормально. Мы Вам выплатили Х рублей. И начали фиксить…
А что сделали Вы? Вы немедленно выложили сюда на Хабр свою первую статью описав все баги, которые Вы «продали» нам, тупо не дав нам времени внести изменения в опубликованный на нашем сайте релиз.
Публиковать баги это нормально, не нормально — получив деньги по bug bounty бежать и сразу писать про них. Подождите чуть-чуть, дайте нам зафиксить и пишите — никто же не запрещает.
Но похоже Вам ближе не идеология исследователей безопасности, а идеология обычных шантажистов. Во второй раз Вы начали разговор с того, что «предложите мне что-то, а не то я напишу на Хабр» (еще упоминался Reddit).
После первого инцидента и второй попытки шантажа какого отношения к себе Вы хотите? Поэтому так…
С первой статьей отправил в почту на несколько адресов, прежде чем выкладывать.
Неделю ответа ждал, причем не «галактическую неделю», а настоящую.
Логи есть, могу выложить.
И предлагал деньги полноценно отработать, чтоб 2й, 3й, 100500й раз даже повода для статей не находилось.
Теперь люди видят, как «фиксят» штакетник и выводы могут сделать.
Неделю ответа ждал, причем не «галактическую неделю», а настоящую.
Логи есть, могу выложить.
И предлагал деньги полноценно отработать, чтоб 2й, 3й, 100500й раз даже повода для статей не находилось.
Теперь люди видят, как «фиксят» штакетник и выводы могут сделать.
Ясно. Понятно. Отправили на несколько адресов и ждали неделю…
А как так получилось, что деньги Вы получили сразу — не было никаких проблем с коммуникациями. Пришли к нам в офис, показали баги — не было проблем с коммуникациями. Во второй раз связались (по телефону) — не было проблем с коммуникациями. Переписывались со мной — не было проблем с коммуникациями.
Но вот выложили первую статью из-за того, что были проблемы с коммуникациями, Вы не могли с нами связаться (уже после получения денег), никто Вам не ответил за неделю.
Вот честно «верю», что именно в этом причина, а не в том, что Вы просто захотели выложить статью пораньше не дав нам исправить баги.
А как так получилось, что деньги Вы получили сразу — не было никаких проблем с коммуникациями. Пришли к нам в офис, показали баги — не было проблем с коммуникациями. Во второй раз связались (по телефону) — не было проблем с коммуникациями. Переписывались со мной — не было проблем с коммуникациями.
Но вот выложили первую статью из-за того, что были проблемы с коммуникациями, Вы не могли с нами связаться (уже после получения денег), никто Вам не ответил за неделю.
Вот честно «верю», что именно в этом причина, а не в том, что Вы просто захотели выложить статью пораньше не дав нам исправить баги.
С вами как раз постоянные проблемы — просто пропадание из эфира.
В этот раз пришлось по телефону, и сильно легче не стало.
Баги вам предлагал исправить еще в прошлом году.
ИМХО, подобного просто не может быть в серьезных системах.
Как минимум год оно простояло после первой статьи не исправленное, и вдруг именно в последней версии с помощью радужных единорогов продукт полностью преобразился.
Тут уже я начинаю не верить.
В этот раз пришлось по телефону, и сильно легче не стало.
Баги вам предлагал исправить еще в прошлом году.
ИМХО, подобного просто не может быть в серьезных системах.
Как минимум год оно простояло после первой статьи не исправленное, и вдруг именно в последней версии с помощью радужных единорогов продукт полностью преобразился.
Тут уже я начинаю не верить.
Да, проблемы со мной. Это ведь я получив деньги побежал сразу описывать все. Я же говорю — идеология исследователей Вам чужда, у исследователей есть негласное правило ждать 60 дней. Ну ОК, очень Вам хотелось, ну дали бы 3 недели, ну позвонили бы. Но нет, ведь цель была в другом. И цель полностью раскрылась во втором инциденте с Вами — получить деньги за сокрытие уязвимостей, т.е. за молчание. Логика ровно обратная исследователям безопасности.
Всего Вам доброго ;)
Всего Вам доброго ;)
С чего решили, что я исследователь?
Да, есть бзик на безопасном программировании, ЛеБланка с МкКонеллом чту как ОтчеНаш.
Просто как разработчик аналогичного функционала увидел откровенно кривую поделку, превозносимую как верх совершенства.
Меньше понтов на семинаре — и темы не было б вообще, а дырки и пофиг.
Для руководителя фирмы удивительно столь однобокое мышление.
Собственно вместо плодотворной совместной работы получили то, что получили.
Да, есть бзик на безопасном программировании, ЛеБланка с МкКонеллом чту как ОтчеНаш.
Просто как разработчик аналогичного функционала увидел откровенно кривую поделку, превозносимую как верх совершенства.
Меньше понтов на семинаре — и темы не было б вообще, а дырки и пофиг.
Для руководителя фирмы удивительно столь однобокое мышление.
Собственно вместо плодотворной совместной работы получили то, что получили.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DLP-система DeviceLock 8.3: прошёл год, Билли, а ты совсем не изменился