Инфобезопасность, как известно, считается по самому слабому звену. И если вы вваливаете и вваливаете (лишние) деньги в ИБ, считая, что на безопасности нельзя экономить - это совершенно не спасает вас от того самого слабого звена: возможность запустить любой(!) исполняемый файл в произвольном, не положенном для исполняемых файлов месте: папка "загрузки", temp, съемные носители, etc. А ведь технологии уже 25 лет - всего лишь настройка в Active directory - политика ограниченного использования программ. Отсутствие которой и привело к 99%, если не 100%, случаев заражений вирусами-шифровальщиками в мире и всем тем экономическим ущербам от них! Я еще понимаю личный комп физлица, который заразился вирусом - о таких вещах как групповые политики неспециалист знать не обязан. Но представим себе: компания с целым ИТ-отделом, возможно даже с раздутым штатом (я, к слову, могу вдвоем обслуживать офис на 200 юзеров - именно потому что есть понимание ИБ), эти люди получают достойную зарплату, но вот они просто - постеснялись/поленились/не додумались за всё свое время хождения на работу включить эту самую политику, просто включить, это бесплатно - и поймали шифровальщика. А технологии было 20 лет! Занавес. Так выглядит практически каждый инцидент с вредоносным ПО в любой компании!
В чем суть и в чем абсолютность такой защиты от вирусов: мы можем запускать только те исполняемые файлы, которые находятся в специально предназначенных для них местах, куда без админских прав записать ничего нельзя. Для вредоносного ПО получается замкнутый круг. Даже изощренная атака через эксплуатацию уязвимостей в PDF и тому подобных файлах документов стандартно реализуется через загрузку вредоноса куда-то на диск и далее его запуск.
Итак, рассмотрим все особенности применения политики - "расслабленный" вариант в плане ограничений:
Обязательно внести в белый список папку C:\Program Files (x86) - по умолчанию ее там нет. Для запуска Autocad потребуется добавить ещё и C:\ProgramData
Внести пути для запуска приложений, размещенных у вас в локальной сети.
Изменить перечень "назначенных типов файлов" - удалить LNK и добавить JS, VBS
Выбрать применение политики "кроме локальных администраторов"
Поставить по умолчанию тип политики "запрещено".
Софт теперь ставим только в Program Files или в сетевую папку на сервере (из белого списка)
Такие настройки позволят в случае необходимости обойти политику, сделав запуск "от имени администратора"
Теперь о том, как воспользоваться защитой на ПК не в домене и даже с домашней версией Windows. Политики хранятся в разделе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Policies. Проверено на Windows 7-10, возможно сработает и на XP. Представим себе: рабочий ноутбук, система уже стоит из магазина, надо его защитить:
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers]
"authenticodeenabled"=dword:00000000
"DefaultLevel"=dword:00000000
"TransparentEnabled"=dword:00000001
"PolicyScope"=dword:00000001
"ExecutableTypes"=hex(7):57,00,53,00,43,00,00,00,56,00,42,00,53,00,00,00,56,00,
42,00,00,00,55,00,52,00,4c,00,00,00,53,00,48,00,53,00,00,00,53,00,43,00,52,
00,00,00,50,00,49,00,46,00,00,00,50,00,43,00,44,00,00,00,4f,00,43,00,58,00,
00,00,4d,00,53,00,54,00,00,00,4d,00,53,00,50,00,00,00,4d,00,53,00,49,00,00,
00,4d,00,53,00,43,00,00,00,4d,00,44,00,45,00,00,00,4d,00,44,00,42,00,00,00,
4a,00,53,00,00,00,49,00,53,00,50,00,00,00,49,00,4e,00,53,00,00,00,49,00,4e,
00,46,00,00,00,48,00,54,00,41,00,00,00,45,00,58,00,45,00,00,00,43,00,52,00,
54,00,00,00,43,00,50,00,4c,00,00,00,43,00,4f,00,4d,00,00,00,43,00,4d,00,44,
00,00,00,42,00,41,00,54,00,00,00,42,00,41,00,53,00,00,00,41,00,44,00,50,00,
00,00,41,00,44,00,45,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths{191cd7fa-f240-4a17-8986-94d480a6c8ca}]
"LastModified"=hex(b):c9,ae,97,63,18,84,d9,01
"Description"=""
"SaferFlags"=dword:00000000
"ItemData"="C:\\Windows"
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths{cea59734-a2f8-487b-ab8a-6267ccd87c31}]
"LastModified"=hex(b):a7,84,29,77,18,84,d9,01
"Description"=""
"SaferFlags"=dword:00000000
"ItemData"="C:\\Program Files"
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths{d2c34ab2-529a-46b2-b293-fc853fce72ea}]
"LastModified"=hex(b):c9,ae,97,63,18,84,d9,01
"Description"=""
"SaferFlags"=dword:00000000
"ItemData"="C:\\Program Files (x86)"
Идём дальше. А что же у нас на Linux? А там просто совершенно не пуганная из-за отсутствия вирусов публика. Съемные носители и вообще любые новые ФС не-nix формата - монтируются прямо с включенным исполняемым атрибутом! И детская болезнь винды с предложением что-то автозапустить при вставлении флэшки. А ведь можно под пользовательскими правами запустить нечто и оно зашифрует всё, до чего можно дотянуться с правами на запись в сети! И чтобы размножаться, вирусу не обязательны root-права! Вангую массовое появление вирусов-шифровальщиков под Linux, особенно из-за геополитики - импортозамещения России Linux-ом и желания на Западе нанести ущерб перешедшей на Linux критической инфраструктуре, при этом может достаться всем - и частникам, и мелкому бизнесу, и в любой стране мира. Поэтому готовиться надо уже заранее! В Debian-based системах есть Apparmor, в RedHat-based есть seLinux. В комментах жду решения как убрать исполняемый атрибут для новопримонтированных файловых систем.
Комментарии (21)
xi-tauw
02.08.2024 12:11А потом вы посмотрите на права в куче папок и узнаете, что внутри C:\Windows есть такие места куда пользователь без прав может что-то положить и выполнить, а если еще поковыряться, то даже можно найти места которые в которые можно писать и исполнять, но нельзя читать.
Пока не успели взгрустнуть читаете о lolbin'ах. Вот тут унываете совсем.
А потом еще узнаете про веселые особенности, типа альтернативных файловых потоков и просто забиваете на все попытки ограничить пользователей. Поскольку реальной проблемы запреты не решают.
noldo32 Автор
02.08.2024 12:11+1Именно из-за такого подхода - "забить на попытки ограничить" - и были все те нашумевшие случаи с шифровальщиками-вымогателями. Вирус запускался не из особых мест или альтернативных потоков, а был просто распакован из архива в письме и запущен тупо из temp! Делаем выводы.
Mur81
02.08.2024 12:11+1Следуя такой логике можно вообще ничего не делать (накрыться простынёй и ползти на кладбище). SRP и AppLocker - один из рубежей обороны, при том достаточно эффективный.
xi-tauw
02.08.2024 12:11Чем больше тех, кто ставит защитой SRP, AppLocker или WDAC, тем проще мне работать на пентестах, спасибо вам.
Mur81
02.08.2024 12:11Напишите статью - поделитесь знаниями чем SRP/AppLocker помогают Вам в пентестах. Я имею в виду почему с ними становится хуже чем без них. Все только спасибо скажут. Кто был не прав - сделают выводы (возможно я ошибаюсь?).
xi-tauw
02.08.2024 12:11Вы переоцениваете смысл такой статьи.
Вся суть, так сказать На аргумент вида "но выглядит же закрыто/безопасно" мне сказать нечего. Но и как "открыть" такую дверь вопросов тоже не вызывает.
Mur81
02.08.2024 12:11Нет, это выглядит так: "У этой технологии есть недостатки, поэтому использовать её не надо/бесполезно". При этом не существует ни одной технологии, которая даёт абсолютную безопасность. В т.ч. тогда бы не нужны были пентестеры - просто делай так-то и ты в абсолютной безопасности.
Данная технология может и должна использоваться в комплексе с другими.
ABRogov
02.08.2024 12:11Ну вроде не хуже, чем вообще без, даже по картинке. Уже случайная мышка, птичка или даже кошка не зайдет. Или что вы хотели сказать?
Re1ter
02.08.2024 12:11Sysinternals GPdisable или тот же GPCul8or обходят эти ограничения ещё со времён той самой Windows XP
noldo32 Автор
02.08.2024 12:11Чтобы запустить что-то обходящее ограничения ГП, нужно запустить исполняемый файл вне положенных мест. Замкнутый круг. Разорвать который можно только документом с эксплойтом.
kenomimi
02.08.2024 12:11+2Кучу софта ставится в профиль пользователя - да что греха таить, сам такой пишу. Потому что подобный подход резко сокращает время на деплой релиза: переустановка с правами админа это долго, бюрократично и так далее, особенно когда клиентов много разношерстных - когда как автообновление в папке пользователя происходит вообще незаметно. Вирусописатели про эту фичу знают, потому вирусы устанавливают себя туда же, в профиль... Тут и сказочке конец, закрыть папки профиля на исполнение нельзя, сломается куча софта.
Плюс большинство шифровальщиков вообще не закрепляются в системе - они стартанули через уязвимость сразу из оперативки, причем в контексте процесса-донора, отработали, исчезли. Им не нужно привлекать к себе внимание.
Mur81
02.08.2024 12:11+1Вот за такое руки отрывать надо (извините - ничего личного). Т.е. вы прекрасно понимая, что делаете не правильно все равно продолжаете это делать т.к. это "резко сокращает время на деплой релиза", "бюрократично и так далее". Вставляя палки в колёса сисадминов, которые внедряют SRP/AppLocker, прекрасно при этом понимая, что вирусописатели этим пользуются.
Я еще могу понять если софт пишется для домашнего сегмента. Но если это софт для корпов, то это крайне печально. Например тот же Chrome имеет "домашний" инсталлятор, который ставит его в профиль и "корпоративный" в виде .msi, который ставит по всем правилам в %ProgramFiles%.
В список грехов можно добавить:
Складывание кэша и прочих временных файлов в %APPDATA% (ломает концепцию перемещаемых профилей).
Использование захардкоженных путей вместо переменных окружения.
kenomimi
02.08.2024 12:11Пример. 240+ клиентов. У кого-то есть средства администрирования, у кого-то админы бегают ручками ставят на тысячи компов (условно), у кого-то админский доступ надо заказывать за месяц у СБ... Выпускаешь релиз и ад у поддержки начался - "ой а у нас нет обещаной кнопочки" - "вы обновились?" - "а мы не можем, согласовывать установку месяц... Но кнопочка нужна, я пошел эскалировать вопрос вашему гене, делайте как хотите без админа..." Дальше вой, рыдания, скандал, ругань, злые отзывы, 9000 звонков на поддержку, задалбывание руководства этими заказчиками.
Магазина приложений на виндах нет - то, что есть, убогое, и в корпоративной среде сразу вырезается. Иного канала распространения софта нет - скачивай по ссылке инсталлятор и от админа переустанавливай, каждый апдейт, а они частые. Либо заводи сервис, который всегда работает от системной учетки и мониторит обновы, но на это многие СБ высказывают свое недовольство. У трех четвертей заказчиков нет системы массового деплоя софта (или доступ зарегулирован бюрократией так, что формально есть, фактически нет), всё ручками - это данность, с которой надо уметь жить.
Именно потому всякие дискорды и прочие часто обновляемые приложения встают в профиль - иных вариантов доставить частые обновы и не достать пользователя, нет.
Mur81
02.08.2024 12:11Почему Вы так делаете я прекрасно понимаю, тут мне объяснять не надо. А знаете почему так всё происходит? Потому что им тоже так удобнее - удобнее отобрать права админа и не иметь при этом средств администрирования, удобнее не иметь дежурного админа который всегда на связи, удобнее иметь безопасников-самодуров и много что еще удобнее. Неудобно потом выкуп за файлы платить только.
Дело в том, что сисадмин и разработчик софта (софта для бизнеса если точнее) работают не для того что бы было как им удобнее, а для того что бы бизнес эффективно работал и зарабатывал деньги. В том числе деньги на их зарплату. Эффективность это в том числе наименьшая уязвимость к всевозможным атакам. Есть правила написания софта под определённую ОС и практики её администрирования. Если бы все придерживались их, то и проблем бы не было.
Вы мне поделились своей болью со стороны разработчика, а я Вам со стороны админа, который потом это обслуживает.
Но однако я привёл в пример Chrome, который эту проблему решил достаточно изящно. И это не единственное ПО, которое пользуется таким подходом (два разных инсталлятора). Подумайте над этим, прошу как админ.
PS Впрочем такой софт на самом деле не ломает под ноль использование SRP/Applocker. Там можно настраивать довольно гибкие исключения, в т.ч. по сертификату подписи и хэшу исполняемого файла. Определённые неудобства вызывает, но не критично.
ABRogov
02.08.2024 12:11+1Я так понял, что вашему оппоненту заказчик прямо говорит: "хочу что бы устанавливалось в папку юзера". Ну тут хозяин - барин, кто программу кормит, тот и платит вымогателям.
noldo32 Автор
02.08.2024 12:11У меня нет и не предвидится той кучи софта, что ставится в профиль пользователя. Но на такой особый случай - в статье как раз был пункт про добавление в белый список запускаемого из сетевой шары софта. Да, проблема решается именно так: на сервере установлено и обновляется когда надо, а папка хардлинком смотрит в шару. Автообновления вообще зло, каждое поделие лезет обновляться, замедляет работу. Вычищаю скриптом все автозагрузки во всей сети - и порядок!
Плюс большинство шифровальщиков вообще не закрепляются в системе - они стартанули через уязвимость сразу из оперативки, причем в контексте процесса-донора, отработали, исчезли. Им не нужно привлекать к себе внимание.
А как же заблокировать экран надписью с вымогательством денег? Иначе смысл было шифровать? Большинству шифровальщиков как раз таки нужно закрепляться в системе и привлекать к себе внимание, требуя выкуп.
alexq234
02.08.2024 12:11В комментах жду решения как убрать исполняемый атрибут для новопримонтированных файловых систем.
Нет необходимости трогать атрибуты. Достаточно монтировать с опцией noexec. См. конфиги udisks2, если дистрибутив на базе debian.
noldo32 Автор
02.08.2024 12:11Смотрел, не влияет на exec bit при автомонтировании новой ФС. Есть пример конфига, который успешно отключил установку exec bit?
Lazhu
С недоступным для исполнения temp будет невозможно запустить DISM или установить софт, установщик которого распаковывается в temp и запускается оттуда.
singerfox
А для этого стоит исключение для администраторов. Т.е. при запуске от админа эти ограничения не действуют.