Как удалить devicelock с компьютера

Обновлено: 03.07.2024

По следам более чем прошлогодней статьи представляю грустное продолжение.

Осенью 2018 года наткнулся на комментарий одного из создателей продукта и решил таки посмотреть, устранены ли дыры в новой версии и попробовать поискать новые.

В итоге обнаружено следующее:

1. Возможность удаления/переименования драйверов устранена установкой более жестких прав доступа к ним.

Данное решение однозначно напрашивалось. Это был единственный плюс, дальше идут минусы:

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

В результате стереть/переименовать системный файл и повалить таким образом службу можно все так же легко.

Пробуем стирать на вид абсолютно никому не нужный winspool.drv, от которого зависит dlservice.exe и перезагружаемся.

Первое, что бросается в глаза, — наличие задержки между входом и падением в синий экран.
Злоумышленник может провернуть темные делишки, но очень по быстрому.

Однако на скоростях интерфейсов USB3 и Thunderbolt можно успеть прокинуть на съемный накопитель сотню-другую мегабайт за ту самую пару секунд между входом в систему и падением.

Второе — система не падает, если не выполнять логин. Т.е. цепляйся по сети со своего ноута, расшаривай С$ и спокойно забирай, что надо, лежит ведь все, в том числе и файрволл! Главное, в терновый кус…, ТЬФУ!, в удаленный рабочий стол не заходи и не логинься — опять упадет!

Ну и наконец третье — пытаемся вместо системной оболочки (по умолчанию естественно проводник), подсунуть скрипт, копирующий что-то большое, напр клиентскую базу, на флешку (и да, ключ реестра на редактирование не закрыт!).

Эффект оказывается забавный — синий экран не появляется и через 10 минут после работы нашего зловредного скрипта!

Суперзащита реагирует на проводник! Для проверки просто запускаем его и получаем синий экран! Т.е. достаточно отключить стандартную оболочку, и защита рушится после удаления системного файла!

Разработчикам из Смарт Лайн, видать, невдомек, что стандартный диалог открытия файла обладает практически полным функционалом проводника по копированию файлов и доступен
сразу после входа в систему из диспетчера задач!

В итоге имеем ровно то, что и предполагал в предыдущей статье: дополнительные саморезы в штакетник вкрутили, но защиту это сильно не усилило.

Удивляет, что настолько топорное решение предлагает фирма, позиционирующая себя как разработчик систем защиты мирового масштаба!

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

Пока ковырялся с этим, случайно обнаружил еще один прикол в стиле прям таки Apple: в консоль управления можно войти от имени обычного пользователя с пустым паролем! Это возможно, если его пароль совпадает с паролем одного из выделенных админов DeviceLock.
Естественно, на моих тестовых виртуалках у всех пароли 8 единиц.

Подход разработчиков просто поразил — это глюк Microsoft и исправлять не собираемся. Вопрос, зачем использовать проблемный компонент, повис в воздухе.

Так же заметил, что механизмы усиления прав доступа сделаны не менее топорно: при установке усиленной самозащиты шаблоны применяются без проверки результатов. Если каким то образом файл удалить или установить заранее права так, что установщик их не сможет поменять, то никакой реакции не будет. Ошибки не появится, а после перезагрузки либо не стартанет сервис, либо файлы останутся доступными для изменения/удаления. И это работа профессионалов — безопасников?

В итоге получаем, что вместо изменения крайне неудачной архитектуры продукта разработчик ограничился корявыми малодейственными заплатками и продолжил развитие в экстенсивном стиле. Служба стала еще больше и ехе-файл уже занимает 18Мб вместо 13!

На предложение сотрудничества по устранению обнаруженного руководство СмартЛайн отреагировало вяло, что еще больше удивляет. Не думал, что в серьезной IT-фирме действует принцип «зачем улучшать, пипл хавает!».

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

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

Как отключить devicelock

  • Как отключить devicelock
  • Как обойти devicelock
  • Как удалить следы от флешек

Отключите автоматический запуск программного обеспечения DeviceLock на вашем компьютере. Вы можете сделать это, изменив меню «Автозапуск» в списке программ, открывающихся через «Пуск». После этого завершите работу используемых приложений, сохраните необходимые данные и перезапустите компьютер. Программ при этом загружена не будет, однако все также может зависеть от типа вашей учетной записи, в некоторых случаях отредактировать список автозагрузки невозможно.

Для завершения работы приложения DeviceLock откройте диспетчер задач операционной системы Windows при помощи нажатия сочетания клавиш Alt+Shift+Esc или Alt+Ctrl+Delete. Найдите процесс программы DeviceLock в ответствующей вкладке открывшегося окна и нажмите на нем правой кнопкой мыши.

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

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

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

Зайдите в панель управления компьютером и откройте меню «Установка и удаление программ», после чего найдите DeviceLock в списке. Удалите ее, следуя указаниям пунктов меню. Также вы можете запустить деинсталлятор из меню программ в списке «Пуск».

В октябре 2017 года довелось побывать на рекламном семинаре DLP-системы DeviceLock, где помимо основного функционала защиты от утечек типа закрытия USB-портов, контекстного анализа почты и буфера обмена рекламировалась защита от администратора. Модель простая и красивая — в маленькую фирму приходит установщик, ставит комплекс программ, паролит БИОС, создает администраторскую учетку DeviceLock, а местному админу оставляет только права на управление собственно Виндой и остальным софтом. Даже в случае умысла этот админ ничего украсть не сможет. Но это все теория…

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

Попытка сделать сразу по завершении семинара не удалась, в лоб защиту от удаления основной службы DlService.exe сделали и даже про права доступа и выбор последней удачной конфигурации не забыли, в результате чего повалить ее, как большинство вирусов, запретив системе доступ на чтение и выполнение, не получилось.

На все вопросы о защите наверняка имеющихся в составе продукта драйверов представитель фирмы-разработчика Смарт Лайн уверенно заявлял, что «все на том же уровне».

Через день решил продолжить изыскания, скачал пробную версию. Сразу же удивил размерчик дистрибутива почти в 2 Гб! Привык, что системное ПО, к которому принято относить средства защиты информации (СЗИ), обычно имеет гораздо более компактный размер.

После установки удивился 2й раз — размер вышеупомянутого ехе-шника тоже весьма немаленький — 13Мб. Сразу подумалось, что при таком объеме есть за что зацепиться. Попробовал подменить модуль с помощью отложенной записи — закрыто. Покопался в каталогах программы, а там одних драйверов аж 11 штук! Потыкал в разрешения — не закрыты для изменения! Ну ладно, всем запрет, перегружаемся!

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

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

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

Причем на рынке полно примеров грамотной реализации защиты от отключения, например отечественные антивирусные средства, где самозащиту просто так не объедешь. Насколько мне известно, они не поленились пройти сертификацию ФСТЭК.

Проведя несколько бесед с сотрудниками Смарт Лайн, несколько подобных мест, о которых они даже не слышали, было найдено. Один из примеров — механизм АррInitDll.

Пусть он не самый глубокий, зато во многих случаях позволяет обойтись без влезания в ядро ОС и не влиять на ее стабильность. Драйвера nVidia во всю используют данный механизм для подстройки видеодаптера под конкретную игру.

Вызывает вопросы полное отсутствие комплексного подхода к построению автоматизированой системы на базе DL 8.2. Предлагается живописать заказчику преимущества продукта, проверить вычислительную мощность имеющихся ПК и серверов (контекстные анализаторы весьма ресурсоемки и модные сейчас офисные моноблоки и неттопы на базе Атом в данном случае не подходят) и просто накатить сверху изделие. При этом такие термины, как «разграничение доступа», «замкнутая программная среда», даже не прозвучали на семинаре. Про шифрование было сказано, что помимо сложности оно вызовет вопросы регуляторов, хотя реально никаких проблем с этим нет. Вопросы про сертификацию даже во ФСТЭК отметаются ввиду их якобы сложности и затянутости. Как специалист по ИБ, неоднократно принимавший участие в подобных процедурах, могу сказать, что в процессе их проведения выявляется множество уязвимостей, подобных описанным в данном материале, т.к. специалисты сертифицирующих лабораторий имеют серьезную профильную подготовку.

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

Реально защитить она может разве что реально большие данные от непривилегированного пользователя, т.к. администратор вполне способен полностью деактивировать защиту, а для необъемных секретов и младший менеджер по клинингу догадается незаметно сфотографировать экран, а то и запомнить адресок или номер кредитки, заглянув в экран через плечо коллеги.
Причем все это справедливо только в случае невозможности физического доступа сотрудников к внутренностям ПК или хотя бы к БИОС для активации загрузки с внешних носителей. Тогда может не помочь даже БитЛокер, который вряд ли применяется в фирмах, которые только задумались о защите информации.

Вывод, как это ни банально звучит, в комплексном подходе к ИБ, включая не только программно/аппаратные решения, но и организационно-технические меры для исключения фото/видеосъемки и недопуска на объект посторонних «мальчиков с феноменальной памятью». Полагаться на чудо-продукт DL 8.2, рекламируемый как одношаговое решение большинства проблем с безопасностью предприятия нельзя ни в коем случае.

В последнее время стало много новостей про случайные утечки различных конфиденциальных данных из веб-сервиса для хостинга IT-проектов и их совместной разработки GitHub.


Подчеркну, что речь пойдет именно о случайных утечках, т.е. произошедших по неосторожности и без злого умысла со стороны виновников инцидентов. Списать такие утечки на неопытность сотрудников в вопросах IT не получится, т.к. пользователи GitHub -это в подавляющем своем числе разработчики, т.е. вполне квалифицированные и грамотные кадры. К сожалению, даже очень хорошие специалисты порой допускают банальные ошибки, особенно если дело касается вопросов безопасности. Давайте считать это халатностью.

Приведу несколько очень известных примеров, связанных с GitHub:

  • 2014 год — компания Uber допустила утечку персональных данных 50 тысяч своих водителей. Причиной было то, что в публичный репозиторий GitHub разработчики Uber сохранили ключи доступа к облаку Amazon (AWS), на котором, в свою очередь, хранились те самые утерянные данные.
  • 2017 год — выяснилось, что разработчики производителя квадрокоптеров DJI сохранили в публичном репозитории GitHub закрытый ключ SSL-сертификата компании и AES-ключи для шифрования прошивок. Кроме того, там же хранились учетные данные для Amazon Web Services, в котором, в свою очередь, находились журналы полетов, данные паспортов и водительских удостоверений клиентов DJI.
  • 2017 год – инженер крупного американского IT-аутсорсера DXC Technologies загрузил ключи доступа к AWS в публичный репозиторий GitHub.
  • 2017 год — в публичном репозитории GitHub обнаружились исходные коды, отчёты и планы разработки нескольких крупных финансовых организаций Канады, США и Японии, которые поместили туда сотрудники индийской аутсорсинговой компании Tata Consultancy Service, чьими заказчиками были пострадавшие финансовые учреждения.

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

Покажу, как можно решить данную конкретную задачу, на примере DeviceLock DLP. Исходные данные у нас такие:

  • Аккаунт на GitHub,
  • Ключ AWS,
  • DeviceLock DLP версии 8.3.

Для начала определим, что защищаемыми данными является ключ AWS и его попадание на GitHub необходимо предотвратить.


Поскольку ключ представляет собой набор байт без каких-либо выраженных сигнатур (да, я знаю о тексте “BEGIN/END PRIVATE KEY” в начале и в конце, но это очень слабая сигнатура и лучше на нее не опираться), то мы будем использовать идентификацию по цифровым отпечаткам.


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


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


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

Давайте теперь попробуем загрузить ключ AWS в репозиторий GitHub.



При этом, если посмотреть в журнал теневого копирования DeviceLock DLP, там можно обнаружить тот самый ключ.


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

Конечно, помимо предотвращения утечки данных на GitHub, можно еще проводить периодическую инвентаризацию репозиториев и выявлять в них информацию, которой там быть не должно. Для целей сканирования репозиториев GitHub созданы бесплатные утилиты Gittyleaks, Git Secrets, Git Hound, Truffle Hog и многие другие.

Читайте также: