Однажды, ко мне обратился знакомый с просьбой посмотреть одну из программ для защиты от утечек данных. Одной из особенностей этого ПО является некая «защита от администратора». Как заявляет разработчик, пользователь, имеющий права локального администратора Windows, ни при каких обстоятельствах не сможет нарушить работу программы. Очень смелое заявление, давайте-ка проверим!
Как известно, администратор в ОС Windows — царь и бог, ему разрешается все что только можно, вплоть до удаления системных файлов и изменения бут-секторов жестких дисков. Само собой, что отключить ту или иную программу администратору не составит труда. Именно поэтому в организациях, опасающихся за конфиденциальность своих данных да и за стабильную работу компьютеров и сети в целом, пользователям в первую очередь урезают права. Конечно, можно возразить, что частенько недобросовестные разработчики пишут свой софт в расчете на работу только из-под админа. Например, такая программа может попытаться записать в ветку реестра HKLM вместо HKCU, хранить какие-то свои данные в каталоге Program Files или даже в Windows. Эти проблемы успешно решаются настройкой прав доступа к ключам реестра и файлам, да и сама Microsoft в свое время написала документ с подобными рекомендациями по запуску таких программ из-под пользователя (могу попробовать его найти). Таким образом, организации, раздающие права админа всем подряд, и при этом заботящиеся об информационной безопасности выглядят, мягко говоря, странно, и квалификация руководителя ИТ отдела начинает вызывать серьезные сомнения.
Вернемся к программному продукту (назовем его X, не хочу заниматься антирекламой). Что из себя представляет этот софт? Он устанавливает в систему службу (исполняемый файл) и набор библиотек. При старте служба запускает драйвер, который, кроме всего прочего, и реализует «защиту от админа». По моим прикидкам, она заключается в:
Что это значит? При попытке удалить или записать что-либо в файл драйвер проверяет, имеет ли пользователь на это право, и если нет, операция отменяется. И правда, попытки удалить/переименовать экзешник или длл-ки закончились сообщением Access denied.
Попробуем зайти с другой стороны — отключим запуск службы в реестре. Но и там нас ждет защита — определенные ключи изменять или удалять драйвер не дает. Естественно, прибить процесс из Task Manager тоже невозможно — «нет доступа».
Сразу возникает мысль — это же типичный руткит! Берем любое средство по поиску руткитов, и оно моментально находит признаки руткита — перехваченные функции. А если пойти дальше и воспользоваться программой RootKit Unhooker, то она прямо на ходу может отключить все эти перехваты и защита от админа теряет свою работоспособность.
Не каждый знает про технологии антируткитов, возразите вы. Поэтому пришлось потратить еще некоторое время на выявление остальных способов обхода мегазащиты.
Если вкратце, то получился вот такой список:
Думаю, список этим не ограничивается, и при желании его можно продолжить.
А уж написать утилиту, которая в один клик обходит защиту и деактивирует X, не составит труда даже для начинающего программиста.
После такого поворота знакомый, конечно, отказался от закупки Х. Какой смысл использовать ПО с защитными функциями, если одна из них оказалась фикцией? Может тогда и другие, более важные возможности Х, сделаны похожим образом?
Зачем же могло понадобиться изобретать велосипед с квадратными колесами, пытаясь таким образом сделать еще одну систему контроля доступа поверх встроенной в windows? Я думаю, разработчикам было заранее известно, что этот велосипед далеко не уедет. Скорее всего, недальновидное руководство дало задание сделать «типа защиту от админа», так, для галочки. Ведь у конкурентов даже такой защиты нет!
А в итоге, выяснилось, что лучше не иметь какого-либо функционала совсем, чем включать в серьезное ПО его жалкое подобие. Такая фикция, всплывая через какое-то время наружу, наносит вред не только продукту, но и имижду всей компании-разработчика.
С другой стороны, я не исключаю, что найдутся, скажем, оригинальные заказчики, которые действительно раздают всем админов и хотят такую «защиту», и в таком случае они выберут именно Х.
У вас другое мнение? Готов обсудить в комментариях.
PS: Вариант загрузки с флешки просьба не рассматривать — мы предполагаем, что у сотрудников нет доступа к BIOS, и системные блоки опечатаны.
Небольшое отступление
Как известно, администратор в ОС Windows — царь и бог, ему разрешается все что только можно, вплоть до удаления системных файлов и изменения бут-секторов жестких дисков. Само собой, что отключить ту или иную программу администратору не составит труда. Именно поэтому в организациях, опасающихся за конфиденциальность своих данных да и за стабильную работу компьютеров и сети в целом, пользователям в первую очередь урезают права. Конечно, можно возразить, что частенько недобросовестные разработчики пишут свой софт в расчете на работу только из-под админа. Например, такая программа может попытаться записать в ветку реестра HKLM вместо HKCU, хранить какие-то свои данные в каталоге Program Files или даже в Windows. Эти проблемы успешно решаются настройкой прав доступа к ключам реестра и файлам, да и сама Microsoft в свое время написала документ с подобными рекомендациями по запуску таких программ из-под пользователя (могу попробовать его найти). Таким образом, организации, раздающие права админа всем подряд, и при этом заботящиеся об информационной безопасности выглядят, мягко говоря, странно, и квалификация руководителя ИТ отдела начинает вызывать серьезные сомнения.
Приступим
Вернемся к программному продукту (назовем его X, не хочу заниматься антирекламой). Что из себя представляет этот софт? Он устанавливает в систему службу (исполняемый файл) и набор библиотек. При старте служба запускает драйвер, который, кроме всего прочего, и реализует «защиту от админа». По моим прикидкам, она заключается в:
- перехвате обращений к файлам
- перехвате обращений к реестру
- перехвате обращений к процессам
Что это значит? При попытке удалить или записать что-либо в файл драйвер проверяет, имеет ли пользователь на это право, и если нет, операция отменяется. И правда, попытки удалить/переименовать экзешник или длл-ки закончились сообщением Access denied.
Попробуем зайти с другой стороны — отключим запуск службы в реестре. Но и там нас ждет защита — определенные ключи изменять или удалять драйвер не дает. Естественно, прибить процесс из Task Manager тоже невозможно — «нет доступа».
Сразу возникает мысль — это же типичный руткит! Берем любое средство по поиску руткитов, и оно моментально находит признаки руткита — перехваченные функции. А если пойти дальше и воспользоваться программой RootKit Unhooker, то она прямо на ходу может отключить все эти перехваты и защита от админа теряет свою работоспособность.
Не каждый знает про технологии антируткитов, возразите вы. Поэтому пришлось потратить еще некоторое время на выявление остальных способов обхода мегазащиты.
Если вкратце, то получился вот такой список:
- правка исполняемого файла напрямую на диске с помощью того же RootKit Unhooker или любого дискового редактора
- переименование любого некритичного системного драйвера в реестре в значения, используемые в X (их можно узнать с помощью утилиты DeviceTree
- загрузка в консоль восстановления (recovery console) и удаление исполняемого файла
- восстановления снимка (snapshot) ОС, сделанного до установки X
Думаю, список этим не ограничивается, и при желании его можно продолжить.
А уж написать утилиту, которая в один клик обходит защиту и деактивирует X, не составит труда даже для начинающего программиста.
После такого поворота знакомый, конечно, отказался от закупки Х. Какой смысл использовать ПО с защитными функциями, если одна из них оказалась фикцией? Может тогда и другие, более важные возможности Х, сделаны похожим образом?
Кто же в дураках?
Зачем же могло понадобиться изобретать велосипед с квадратными колесами, пытаясь таким образом сделать еще одну систему контроля доступа поверх встроенной в windows? Я думаю, разработчикам было заранее известно, что этот велосипед далеко не уедет. Скорее всего, недальновидное руководство дало задание сделать «типа защиту от админа», так, для галочки. Ведь у конкурентов даже такой защиты нет!
А в итоге, выяснилось, что лучше не иметь какого-либо функционала совсем, чем включать в серьезное ПО его жалкое подобие. Такая фикция, всплывая через какое-то время наружу, наносит вред не только продукту, но и имижду всей компании-разработчика.
С другой стороны, я не исключаю, что найдутся, скажем, оригинальные заказчики, которые действительно раздают всем админов и хотят такую «защиту», и в таком случае они выберут именно Х.
У вас другое мнение? Готов обсудить в комментариях.
PS: Вариант загрузки с флешки просьба не рассматривать — мы предполагаем, что у сотрудников нет доступа к BIOS, и системные блоки опечатаны.