Осенью 2018 года наткнулся на комментарий одного из создателей продукта и решил таки посмотреть, устранены ли дыры в новой версии и попробовать поискать новые.
В итоге обнаружено следующее:
1. Возможность удаления/переименования драйверов устранена установкой более жестких прав доступа к ним.
Данное решение однозначно напрашивалось. Это был единственный плюс, дальше идут минусы:
2. Защита системных файлов оставлена «как есть», вероятно, с целью обеспечения работоспособности механизмов обновления операционной системы.
В результате стереть/переименовать системный файл и повалить таким образом службу можно все так же легко.
Пробуем стирать на вид абсолютно никому не нужный winspool.drv, от которого зависит dlservice.exe и перезагружаемся.
Входим в систему, видим в диспетчере задач, что служба не запустилась и… оппа! Синий экран!
Перегружаемся, входим и снова синий! Возвращаем файл на место, перегружаемся. Служба запущена, ничего не падает! Вот ведь хитрецы, защиту сделали! Браво? — Не спешите!
Первое, что бросается в глаза, — наличие задержки между входом и падением в синий экран.
Злоумышленник может провернуть темные делишки, но очень по быстрому.
Однако на скоростях интерфейсов USB3 и Thunderbolt можно успеть прокинуть на съемный накопитель сотню-другую мегабайт за ту самую пару секунд между входом в систему и падением.
Второе — система не падает, если не выполнять логин. Т.е. цепляйся по сети со своего ноута, расшаривай С$ и спокойно забирай, что надо, лежит ведь все, в том числе и файрволл! Главное, в терновый кус…, ТЬФУ!, в удаленный рабочий стол не заходи и не логинься — опять упадет!
Ну и наконец третье — пытаемся вместо системной оболочки (по умолчанию естественно проводник), подсунуть скрипт, копирующий что-то большое, напр клиентскую базу, на флешку (и да, ключ реестра на редактирование не закрыт!).
Эффект оказывается забавный — синий экран не появляется и через 10 минут после работы нашего зловредного скрипта!
Суперзащита реагирует на проводник! Для проверки просто запускаем его и получаем синий экран! Т.е. достаточно отключить стандартную оболочку, и защита рушится после удаления системного файла!
Разработчикам из Смарт Лайн, видать, невдомек, что стандартный диалог открытия файла обладает практически полным функционалом проводника по копированию файлов и доступен
сразу после входа в систему из диспетчера задач!
В итоге имеем ровно то, что и предполагал в предыдущей статье: дополнительные саморезы в штакетник вкрутили, но защиту это сильно не усилило.
Удивляет, что настолько топорное решение предлагает фирма, позиционирующая себя как разработчик систем защиты мирового масштаба!
Более того, о простых пользователях думают в последнюю очередь, ибо в случае любого сбоя с порчей системных файлов эта чудо-защита просто парализует штатную работу компьютера и будет потрачено немаленькое время на восстановление, если поблизости нет квалифицированного персонала.
Пока ковырялся с этим, случайно обнаружил еще один прикол в стиле прям таки Apple: в консоль управления можно войти от имени обычного пользователя с пустым паролем! Это возможно, если его пароль совпадает с паролем одного из выделенных админов DeviceLock.
Естественно, на моих тестовых виртуалках у всех пароли 8 единиц.
Подход разработчиков просто поразил — это глюк Microsoft и исправлять не собираемся. Вопрос, зачем использовать проблемный компонент, повис в воздухе.
Так же заметил, что механизмы усиления прав доступа сделаны не менее топорно: при установке усиленной самозащиты шаблоны применяются без проверки результатов. Если каким то образом файл удалить или установить заранее права так, что установщик их не сможет поменять, то никакой реакции не будет. Ошибки не появится, а после перезагрузки либо не стартанет сервис, либо файлы останутся доступными для изменения/удаления. И это работа профессионалов — безопасников?
В итоге получаем, что вместо изменения крайне неудачной архитектуры продукта разработчик ограничился корявыми малодейственными заплатками и продолжил развитие в экстенсивном стиле. Служба стала еще больше и ехе-файл уже занимает 18Мб вместо 13!
На предложение сотрудничества по устранению обнаруженного руководство СмартЛайн отреагировало вяло, что еще больше удивляет. Не думал, что в серьезной IT-фирме действует принцип «зачем улучшать, пипл хавает!».
Сколько еще проблем имеет данный продукт, остается только гадать, т.к. ковыряться дальше бесплатно просто лениво. Пользоваться им крайне не рекомендуется, о чем говорилось и более года назад.
Комментарии (46)
ashotog
19.03.2019 14:47+1про пароли пользователей совпадающие это у вас не вызывает диссонанса? нет? вы можете просто залогиниться под админом, если его пароль такой же как у вашего «простого» юзера, зачем сюда приплетать нашу защиту? я же про это вам говорил уже…
ashotog
19.03.2019 14:51+5и сразу видно по статье, что на новой версии (ей больше месяца) вы ничего не проверяли.
и «сотрудничество», как вы его называете заключалось бы в фактическом оплате вашего шантажа — вы предлагали не публиковать статью за деньги. поэтому говорить то собственно было и не о чем…
повторюсь, что гарантированная защита от админа в винде невозможна. можно лишь немного усложнить жизнь.
vilgeforce
19.03.2019 14:55Есть подозрение, что загрузка вредоносного драйвера раньше, чем загрузится драйвер защитного средства — не «немного усложнить жизнь»
Ralari Автор
19.03.2019 15:20-3Ну допустим антивирь параллельно работает, но вот валиться из-за левой библиотечки — это ни в какие ворота.
Нас так не учили в институте ошибки обрабатывать.vilgeforce
19.03.2019 15:22Понятно что это косяк. Но, как я понял, разработчик этой софтины утверждает, будто админ может сломать все что угодно и жизнь ему при этом можно лишь «немного усложнить». Я же высказываю подозрения, что можно не «немного»
Ralari Автор
19.03.2019 15:27-2Они это утверждают только здесь, среди проф аудитории.
На рекламных семинарах в СофтЛайне, к примеру, про такие интимные подробности ни слова!
В качестве примера смотрите самозащиту Каспера и ДрВеба.vilgeforce
19.03.2019 15:28О самозащите Dr.Web я знаю не по наслышке. Я видел как нас выносили трои на раз, видел как все это дорабатывалось, доделывалось, ломалось и так далее. Потому и сомневаюсь что админ так уж всемогущ :-)
msuhanov
19.03.2019 15:33+2В качестве примера смотрите самозащиту Каспера и ДрВеба.
При наличии прав администратора – отключается (есть способы). Такой обход за уязвимость производители не считают.Ralari Автор
19.03.2019 15:36-1Ессно есть.
Даже тулзы специальные разработаны самими производителями.
Но вот так вот, что мышкой тыкнуть пару раз, такого нет.TheDaemon
19.03.2019 15:50Прошу прощения, но если Ваш нарушитель может тыкнуть мышкой и удалить часть системных файлов СЗИ, что ему мешает тыкнуть в иконку «специальной тулзы производителя»? Или я неправильно понял вектор атаки?
Ralari Автор
19.03.2019 16:08-2Не «часть системных файлов СЗИ», а «часть системных файлов ОС»
Саму СЗИ они таки смогли защитить, а файлы Винды нет, понадеявшись на мощь синего экрана.
Плюс ко всему забыли про возможность менять системный шелл, а это за гранью, ИМХО.
Специальная тулза как минимум просит капчу, т.е. есть намек на защиту от ботов.
TheDaemon
19.03.2019 15:34+1Нормальная самозащита софта от другого софта, работающего на том же уровне привилегий на текущей x86 архитектуре принципиально невозможна. Т.е. защитить драйвер от драйвера, гипервизор от гипервизора и т.д. нельзя. Можно только осложнить взлом. Вкладывать ресурсы в такую защиту имеет смысл только если вы рассчитываете на НЕ-целевые атаки (антивирус общего назначения).
Ralari Автор
19.03.2019 15:40Повредить файлик можно и с пользовательского режима умудриться или сбой в файловой системе произойдет.
Нормальная реакция — блокировка всего и смс администратору, а не полностью открытое состояние.
Особенно прикольно, что драйвера то остаются работать, контроль над системой сохранить легко.
Но почему-то все завязано на странную службу.TheDaemon
19.03.2019 15:45+1Вы абсолютно правы, что возможны «случайные» модификации файлов, поэтому в нормальных защищенных системах до сих пор применяют средства доверенной загрузки, в функции которых входит и контроль целостности СЗИ и среды функционирования (ОС), до ее запуска.
Блокировка — нормальная реакция системы защиты на факт НСД. Но если система защиты отключена (по какой-то причине), то она не может ничего заблокировать.
P/S: Я никоим образом не защищаю конкретную систему, и вполне допускаю, что она «отстой». Просто статья довольно сумбурная и было бы неплохо ввести в нее дополнительные уточнения по модели угроз, тому как она соответствует предлагаемым векторам атак и т.д.Ralari Автор
19.03.2019 15:52Почитайте предыдущую статью, чтоб не повторяться.
Тут проблема в архитектуре.
Как обычно программная СЗИ состоит из драйвера(ов) и службы.
Валится служба, драйверы остаются.
Казалось бы есть все условия для сохранения уровня защищенности, но нет.
Я специально не акцентирую внимание на загрузку с альтернативного носителя, ибо ни одна чисто программная СЗИ с этим не справится.
Допустим, что БИОС запаролен, комп опечатан и с УСБ не загрузишься.
АПМДЗ не проходит ибо по цене будет космос.Kobalt_x
19.03.2019 21:26+2от антивируса вы тоже считаете, что когда валится служба а драйвер остается полного сохранения уровня защищенности? HIPS/OAS в драйвере ага конечно.
Хотя были конечно веселые прецеденты(symantec) отгребания bsod/kexec через битый архив.Ralari Автор
20.03.2019 11:08-1Ожидаю адекватного поведения.
Обычно драйвер что-то блокирует, служба управляет, т.е. дает команды на разблокировку, к примеру, УСБ-накопителя.
Если службу уронить, то блокировки продолжат работать, информация останется защищена.
Тут же все точно наоборот.
Еще в прошлой статье указывал на 2 архитектурные проблемы продукта, которые разработчик устранять не собирается.
1. Изначально неверный подход к установке блокировок.
По умолчанию должно быть ЗАКРЫТО, а только после проверки блокировки должны сниматься.
2. Неправильно написанная служба. По правилам из МСДН на голом С пишется каркас службы с обработчиками ServiceStart ServiceStop и т.п., весь остальной функционал на MFC или дотНет подгружается динамически. В данном случае это полностью исключает возможность повалить службу удаляя второстепенные файлы.
По ощущениям кто-то в 90х написал тестик для диплома или УИРа, а потом вокруг него коммерческий продукт, и так все лень перепсать по нормальному.
msuhanov
19.03.2019 16:23применяют средства доверенной загрузки, в функции которых входит и контроль целостности СЗИ и среды функционирования (ОС), до ее запуска
Предзагрузочный контроль целостности невозможен. Я могу изменить реестр так, что контролирующий компонент изменение не заметит, а ядро ОС – заметит. Я могу создать файл, содержимое которого для контролирующего компонента будет одно, а для драйвера NTFS – файл будет пустым. Потому что нельзя написать код, полностью повторяющий парсинг того, что контролируется.TheDaemon
19.03.2019 20:08Извините, не совсем понял, могли бы пояснить? До запуска основной ОС можно контролировать целостность из модуля UEFI (Secure Boot?), из аппаратного модуля с Option ROM, из загрузчика, лежащего на аппаратно-ридонли флешке, установленной внутри корпуса и т.д. Если рассматривать возможность вскрытия корпуса, то, конечно, защита возможна только относительная (корневой ключ, зашитый в проц на производстве и надежда, что Китайцы не смогут выпустить свой процессор, но с другим ключем).
Я не очень понимаю, почему нельзя написать код, который будет повторять парсинг того, что контролируется? Я могу просто воспользоваться тем же драйвером, что и винда :) РеактОС вон грузит виндовые драйвера, что мешает то же самое сделать в контролирующем компоненте?msuhanov
19.03.2019 21:39Secure 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. Но это же столько отечественных научных работ по доверенной загрузке нужно признать несостоятельными.TheDaemon
19.03.2019 23:371. В итоге, ваше утверждение
Предзагрузочный контроль целостности невозможен.
сводится к банальной проблеме останова, теореме Райса и т.д. Т.е. вы апелируете к тому, что в конкретных реализациях (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'ом и поэтессами, ничего лучше пока никто не предложил.msuhanov
20.03.2019 00:13Почему вы считаете, что в модуле 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 при сбое не получить). Но это уже другая история.TheDaemon
20.03.2019 01:38Я лишь утверждаю, что поэтапный контроль лучше.
АПМДЗ является частым случаем реализации одной из стадий поэтапного контроля. Это такой же кусок кода, как и сам winload. Они одновременно находятся в одной и той же памяти и исполняются одновременно на одном уровне привелегий. От того, что вы расположите их в одном PE или в разных ничего не поменяется.
Еще раз повторю: вы говорите о различиях в реализации парсинга в winload'е и АПМДЗ, что является частным случаем ошибки/уязвимости. Точно такие же ошибки есть в любом коде, будь то Secure Boot или любая другая система защиты.
Есть множество статей о реальных уязвимостях в конкретных реализациях Secure Boot'а.
Ничего не мешает АПМДЗ проверять целостность реестра и наличие драйвера СЗИ уже в памяти по ExitBootServices. Можно использовать для проверки реестра в памяти куски кода winload'а, вызывая их из своего UEFI-модуля. Можно исполнять все, вплоть до получения управления драйвером в тонком гипервизоре (blue pill/bitvisor) и контролировать целостность всех исполняемых страниц памяти при их вызове (ага, мы так умеем). Можно написать свой загрузчик винды, который будет использовать тот же код (ReactOS'овский XP грузил на ура). На любой названный вами вектор атаки я всегда смогу ответить методом защиты. Это обычное соревнование брони и снаряда. Вы будете усложнять потенциальные атаки, а я защиту, а остановится это там, где разработка методов атаки станет слишком дорогой.
Также учтите, что ФСБ, например, выдает заключение на винду только в составе с конкретным СЗИ. Т.е. рассматривается всегда комплекс: АПМДЗ, СЗИ, среда функционирования (ОС + Железо).
Если вдруг Вы хотите ответ по конкретным предложенным атакам, хотя это ничего и не доказывает, то вот:
winload не умеет в файлы транзакций, так что ничем не отличается даже от аккорда. Незакрытые транзации закроет уже ядро, а все бутовые драйвера, загруженные winload'ом, получат управление.
В модель угроз не входит возможность исполнить код в ядре, а без этого вы NTFS не поломаете. Ни одно СЗИ на (не только Российское) не сможет защититься от кода на том же уровне привелегий. Для систем выше КС3 требуется обеспечение замкнутости программной среды, т.е. СЗИ проверяет ВЕСЬ исполняемый в системе код, а не только код, исполняемый в ядре. КС3 и ниже — тупой ленивый нарушитель. Уязвимости (и в ядре и в юзер моде) рассматриваются как нечто обязательно присутствующее и, согласно современным требованиям, любые СЗИ + ОС обязаны реализовывать меры по снижению вероятности эксплуатации: CFG, ASLR и т.д. Все понимают, что абсолютной защиты небывает.
Я не знаю ниодного сертифицированного дистрибутива с СЗИ, использующего dracut. Но если есть опубликованная уязвимость или документированная возможность, позволяющая «на лету заменить ядро», при сертификации это бы закрыли.
Ничего не забыл? Т.е. ни одна из предложенных вами атак в реальной жизни не сработает. Это вовсе не означает, что вы не сможете найти уязвимость.msuhanov
20.03.2019 02:11АПМДЗ является частым случаем реализации одной из стадий поэтапного контроля. Это такой же кусок кода, как и сам 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 вы не «реверсили», а потому, согласно вашему заблуждению, предложенные мной атаки не работают.msuhanov
20.03.2019 02:18winload.efi
TheDaemon
20.03.2019 08:481. В итоге я все еще уверен, что утверждение
Предзагрузочный контроль целостности невозможен.
является сильным преувеличением.
Если бы Вы сказали «Предзагрузочный контроль целостности пораждает ряд векторов атак, которых нет в Secure Boot», это было бы гораздо ближе к правде.
Очень хорошо, что Вы про них знаете. Но я не вижу принципиальных сложностьей в борьбе с ними.
2. Я Вам верю, что ошибся, так как действительно лично не изучал как работает winload с реестром, а воспользовался информацией полученной от коллег. Большое спасибо, что Вы изучили и об этом рассказали. Тем не менее, даже учитывая, что winload работает с логом транзакций, я не вижу принципиальной сложности в реализации. Если сложно транзакции имплементировать можно просто удалять лог для проверяемых веток или помечать ветку чистой (поправив sequence + чексумму). Запись в них в нормальной работе СЗИ произвоится все равно не должна.
3. В моем понимани, единственное что должен гарантировать АПМДЗ с точки зрения контроля целостности — это то, что СЗИ работающее в Windows получит управление. Я уже указал, что для СЗИ под Windows сейчас работает подход с виртуализацией, а для Linux СЗИ встроенно в ядро, поэтому достаточно контролировать его и initramfs перед kexec'ом.
4. Актуальней будет, если вы укажете на разницу при использовании Linux. До этого вы писали про разные версии драйверов/ядер, а я не понял к чему это, так как АПМДЗ контролирует только то, что грузит в память, во время kexec -l, т.е. ядро и initramfs. В моем понимании это никак не отличается от Secure Boot.
5. Какой вы можете предложить альтернативный путь? Переписать винду/отказаться от винды? Так этим путем и идет наше государство, пересаживаясь на Linux.
6. Если Вы этот разговор закончили, хотел бы сказать большое спасибо, было позновательно и интересно. Побольше бы таких осведомленных комментаторов.Ralari Автор
20.03.2019 11:15Интересно было почитать про АПМДЗ, т.к. по работе мы с ними не пересекаемся. Даже сквозной логин из замка в ОС регуляторы запрещают.
Применительно к рассматриваемому продукту применение АПМДЗ клиентами не рассматривается из-за цены.TheDaemon
20.03.2019 13:16Надо будет написать статью про современные АПМДЗ как-нибудь, а то много заблуждений основанных на опыте общения со старинными DOS'овыми железками бытует :)
Странные у вас регуляторы. У нас в рамках всех СЗИ (и Win и Linux) есть Authentication Package и PAM-модули для SSO и даже релогина замковых пользователей, включая удаленную аутентификацию, смену аутентифицирующей информации и т.д.
Про цену — это абсолютно верно. Аппаратные замки оправданы только начиная с класса КС3, а таких систем не так уж и много.Ralari Автор
20.03.2019 14:17Мы сделали Джину под НТ 4.0, берущую данные из нашего же АПМДЗ, восьмерики сказали нет.
Под Астру не в курсе, работу поменял.
Может и разрешат РАМ модуль сделать
TheDaemon
20.03.2019 08:56Кстати, я уже пользовался вашим yarp'ом и не узнал в Вас автора. Полезная тулза :)
vilgeforce
19.03.2019 15:57Именно поэтому кто первый встал — того и тапки, то есть загружать драйвер надо как можно раньше и препятствовать попыткам других драйверов вынести хороший. Приведенные выше примеры так умеют
Ralari Автор
19.03.2019 14:58-3Могу выложить переписку.
Предлагал решить архитектурные проблемы, ибо опыт имею 20 летний именно в этом вопросе.
Функционал DLP в разрабатываемой с моим участием системе был лишь одним маленьким винтиком.
С паролями такого не должно быть, потому что не должно быть никогда!
При сертификации есть 30 лет назад разработанные методики проверки и это бы нашлось.
но вы же выше этого, сертификация — не царское дело.
Офицер может напутать листки с паролями при раздаче.
sergunec
19.03.2019 15:05Сколько же крови мне попил этот «великий» продукт мирового уровня во время работы в поддержке. Но у СБ все хорошо — это Windows кривая.
TheDaemon
19.03.2019 15:28+4Вообще не понятно в рамках какой модели угроз проводилось тестирование. Если считать админа нарушителем, то что ему мешает загрузиться с флешки, открутить нафиг DLP из реестра и радоваться жизни?
В заключении на СЗИ (а, судя по сайту, на эту штуку есть сертификат ФСТЭК), всегда есть ограничительная часть, в которой указано от чего оно защищает. Если вы выходите за рамки этой ограничительной части, то ваши тесты ни о чем не говорят.ashotog
19.03.2019 15:34+2там тестирование уровня Бог. пока я намеками не выяснил, что у админа и простого юзера совпадают пароли, мне предлагалось «купить» эту уязвимость. и до сих пор автор продолжает настаивать, что это нормально, когда пароли совпадают…
Ralari Автор
19.03.2019 15:47Именно так системы и тестируют.
И все это ловится на виртуалках либо стенде.
Про ФСТЭК уже обсуждалось — единственный простенький профиль на работу со сменными носителями.
Никаких РД АС по серьезным уровням и близко нет.TheDaemon
19.03.2019 16:00Я, например, не знал, что «про ФСТЭК уже обсуждалось», а в статье этого не увидел.
Вы говорите правильные вещи, которые надо было указать в статье, чтобы она собрала плюсов:
— на что сертифицировано данное изделие
— модель угроз со ссылкой на правила пользования изделием
— методики тестирования с описанием вашего стенда
— ваши предложения по улучшению данной системы и т.д.
Если сделать статью более системной, отношение к ней может измениться как у читателей, так и у производителя.
На мой взгляд, на текущий момент и статья и реакция производителя слишком эмоциональны, что в таких вопросах явно лишнее.Ralari Автор
19.03.2019 16:14Обсуждалось в комментах к первой статье.
И пришел не плюсы собирать, хотя это и приятно. :)
Методики, стенды, испытания — моя работа, и так от нее тошнит…
Реакция производителя просто удивительная.
Можно было еще в 17 году привлечь команду и сделать хотя бы прототип с нормальной архитектурой.
Ralari Автор
19.03.2019 15:42-1Аппаратуру не рассматривал, ибо и так все ясно.
Собсно вусе в виртуалке крутилось.
ashotog
19.03.2019 16:12+5На предложение сотрудничества по устранению обнаруженного руководство СмартЛайн отреагировало вяло, что еще больше удивляет.
Виталий, а что Вас собственно удивляет? давайте я напомню тем, кто не в теме, как Вы поступили в первый раз (с первой статьей)?
Вы пришли к нам, сказав, что обнаружили два бага в самозащите и попросили денег. Bug bounty это нормально. Мы Вам выплатили Х рублей. И начали фиксить…
А что сделали Вы? Вы немедленно выложили сюда на Хабр свою первую статью описав все баги, которые Вы «продали» нам, тупо не дав нам времени внести изменения в опубликованный на нашем сайте релиз.
Публиковать баги это нормально, не нормально — получив деньги по bug bounty бежать и сразу писать про них. Подождите чуть-чуть, дайте нам зафиксить и пишите — никто же не запрещает.
Но похоже Вам ближе не идеология исследователей безопасности, а идеология обычных шантажистов. Во второй раз Вы начали разговор с того, что «предложите мне что-то, а не то я напишу на Хабр» (еще упоминался Reddit).
После первого инцидента и второй попытки шантажа какого отношения к себе Вы хотите? Поэтому так…
Ralari Автор
19.03.2019 16:20-5С первой статьей отправил в почту на несколько адресов, прежде чем выкладывать.
Неделю ответа ждал, причем не «галактическую неделю», а настоящую.
Логи есть, могу выложить.
И предлагал деньги полноценно отработать, чтоб 2й, 3й, 100500й раз даже повода для статей не находилось.
Теперь люди видят, как «фиксят» штакетник и выводы могут сделать.ashotog
19.03.2019 16:45+5Ясно. Понятно. Отправили на несколько адресов и ждали неделю…
А как так получилось, что деньги Вы получили сразу — не было никаких проблем с коммуникациями. Пришли к нам в офис, показали баги — не было проблем с коммуникациями. Во второй раз связались (по телефону) — не было проблем с коммуникациями. Переписывались со мной — не было проблем с коммуникациями.
Но вот выложили первую статью из-за того, что были проблемы с коммуникациями, Вы не могли с нами связаться (уже после получения денег), никто Вам не ответил за неделю.
Вот честно «верю», что именно в этом причина, а не в том, что Вы просто захотели выложить статью пораньше не дав нам исправить баги.
Ralari Автор
19.03.2019 16:55-6С вами как раз постоянные проблемы — просто пропадание из эфира.
В этот раз пришлось по телефону, и сильно легче не стало.
Баги вам предлагал исправить еще в прошлом году.
ИМХО, подобного просто не может быть в серьезных системах.
Как минимум год оно простояло после первой статьи не исправленное, и вдруг именно в последней версии с помощью радужных единорогов продукт полностью преобразился.
Тут уже я начинаю не верить.ashotog
19.03.2019 17:02+4Да, проблемы со мной. Это ведь я получив деньги побежал сразу описывать все. Я же говорю — идеология исследователей Вам чужда, у исследователей есть негласное правило ждать 60 дней. Ну ОК, очень Вам хотелось, ну дали бы 3 недели, ну позвонили бы. Но нет, ведь цель была в другом. И цель полностью раскрылась во втором инциденте с Вами — получить деньги за сокрытие уязвимостей, т.е. за молчание. Логика ровно обратная исследователям безопасности.
Всего Вам доброго ;)
Ralari Автор
19.03.2019 17:11-3С чего решили, что я исследователь?
Да, есть бзик на безопасном программировании, ЛеБланка с МкКонеллом чту как ОтчеНаш.
Просто как разработчик аналогичного функционала увидел откровенно кривую поделку, превозносимую как верх совершенства.
Меньше понтов на семинаре — и темы не было б вообще, а дырки и пофиг.
Для руководителя фирмы удивительно столь однобокое мышление.
Собственно вместо плодотворной совместной работы получили то, что получили.
mwizard
Ожидаемо.