Как стать автором
Обновить

Комментарии 38

НЛО прилетело и опубликовало эту надпись здесь
авторы PowerWare изначально просят $500 выкупа

Дешевле выпустить внутренний документ, запрещающий понижать безопасность макросов.
Если макросы нужны, то создать пользователю сертификат в ветке "Доверенные корневые центры сертификации" (да хоть в ГОСТ Р 34.11/34.10-2001, которых в каждой конторе навалом), а к нему привязать сертификат для подписи макросов — поместить в ветку "Доверенные издатели". Устанавливаем безопасность макросов "Отключить все макросы кроме макросов с цифровой подписью".
Печально.
До этого времени в моей практике от вымогателей удавалось успешно спасаться используя локальные политики безопасности запрещающие запуск приложений и скриптов из пользовательских папок…
Но если начнут лезть через ворд… то даже и не знаю, что делать тогда. Запуск макросов не отключить, он многим нужен в работе. Сам ворд тоже нужен.
Вредоносные документы пока что легко определяются в почте (я пока что не встречал других способов распространения таких штук) — в письме используются общие фразы "высылаем вам акт" и тому подобные, а при запуске такого ворда (если всё правильно настроено) появится окошко "документ содержит макросы, отключить?" — и всё, закрываете документ и shift+delete. Главное научить пользователей не тыкать "включить макросы" при загрузке такого документа и, конечно же, всегда иметь актуальные резервные копии для всего парка машин.
Создаем сертификат для подписывания кода. Добавляем этот сертификат в доверенные издатели. Подписываем нужные нам макросы и скрипты PS этим сертификатом. Не подписанное содержимое запрещаем выполнять.
Самоподписанный сертификат, на домашнем компьютере. Или выданный центром сертификации в корпоративной инфраструктуре. Все это бесплатно.
Мои глаза болеть гугл транслейт нет пожалуйста просить.
Вычитывайте пожалуйста текст перед тем как запостить.
— Эй, антивирус! Ворд создал экзешник и они вместе что-то скачивают!
— Всё ок, сигнатур таких нет.
— О! А вот ещё. Тут в радиусе 100км никто никогда js файлы вручную не запускал, а тут вдруг запустили и оно меняет все подряд файлы!
— Не, не, всё в порядке…
Не создал, а запустил.
Ну скачивает, повершеллу не запрещено скачивать, как и любым другим программам. Это проблема не антивируса, а фаерволла.
Не если вы не видите суслика, то не значит, что его нет. Сигнатуры на все js не создашь, а ограничивать разработчиков в полете их фантазии не совсем верно. Я в колледже, когда админил было такое, что студенты прибегали и ругались что Kaspersky Gold не дает им файлы компилить в дельфи на безобидных программах. Тоже ничего хорошего.
А вдруг я захотел зашифровать все свои файлы. По-быстрому. В дверь то уже ломятся. Почему честно купленный антивирус меня должен ограничивать?
Антивирус, как и фаервол, не должны блокировать угрозу, насколько бы опасной она не была. Они должны спрашивать решения у пользователя. Но тот же ворд при активации макроса, или та же винда при запуске js файла, спросят, а действительно ли пользователь хочет выполнить это действие, ведь оно потенциально опасно, но пользователь соглашается. Если антивирус не заметил угрозу — проблема в антивирусе, а если пользователь пропустил угрозу, которую заметил антивирус — то пользователю уже ничего не поможет, он найдёт способ как затащить угрозу в систему. Ну а то, что антивирусные базы содержат сигнатуру, которую можно встретить в болванке приложения на Delphi — это косяк антивирусов, некоторые из которых даже эту страницу могут посчитать опасной, если разметить на ней "вредоносный код" из их базы.
|Антивирус, как и фаервол, не должны блокировать угрозу, насколько бы опасной она не была. Они должны спрашивать решения у пользователя.
Оу. У Вас нет на поддержке 3к+ пользователей. Иначе такие глупые мысли Вам бы в голову даже не пришли.
У пользователя по умолчанию ничего спрашивать не нужно, нужно выбирать самое безопасное действие на своё усмотрение.
Тем кто по опытнее дать возможность на свой страх и риск залезть в настройки и выставить галочки на своё усмотрение.
Вы слишком много хотите от антивирусов и от пользователей. Что первые, что и вторые — не совершенны.
Вместо того, чтобы объяснить пользователю суть проблемы, вы предлагаете не разрешать ему включать компьютер. Наверное это идеальное решение проблемы взаимодействия пользователя и компьютера, но скорее всего пользователь так же не сможет решать поставленные задачи.
| вы предлагаете не разрешать ему включать компьютер
Где? =)
«Антивирус, как и фаервол, не должны блокировать угрозу, насколько бы опасной она не была. Они должны спрашивать решения у пользователя.»

WAT?????
NTG!!!!11
Я хотел сказать лишь о том, что у пользователя должен быть выбор, а не просто окошко с уведомлением о том, что угроза была заблокирована. Например на случай, если антивирус ругается на то, что в тхт файле содержится особо опасный вирус и поэтому его нельзя открывать.
Если это домашний компьютер, я согласен, что у пользователя должен быть выбор, поскольку за свои действия он отвечает сам. В случае компьютера в компании, наверное все таки лучшим способом будет автоматическая блокировка в любом случае.
Так в большинстве случаев и делают. Вместо того, чтобы объяснить пользователям банальные правила безопасного поведения в сети, им ограничивают доступ, закрывают фаерволами и групповыми политиками. И всё замечательно работает ровно до тех пор, пока какое-нибудь из средств защиты не даёт сбой: антиспам пропустит письмо, антивирус не заметит новую сборку или пользователь скачает свежих котиков с расширением ps1. Это, блин, как закрывать фаерволом порт сервиса, который поддерживает авторизацию, но настроить её нормально лень. Но конечно же, вместо того, чтобы потратить час на написание инструкции с описанием типичных векторов атак или день на съёмки обучающего ролика, проще сказать что пользователи тупые и сами о себе позаботиться не смогут, тем более что их много, а я один. Конечно же не у всех всё настолько плохо, но большинство тех компаний, которых мне довелось проаудировать, полагались или на защиту софта или ещё хуже, на защиту того же софта установленного на отдельную железку и купленную за какие то сказочные деньги. И защита иногда даже работает, особенно если атаки имеют массовый характер, но стоит провести таргетированную атаку и софт лажает, атака доходит до пользователей, и если атакующий знает какие именно возможности у пользователя на ПК заблокированы, он подберёт такой вектор, что защитить пользователя сможет только он сам.
НЛО прилетело и опубликовало эту надпись здесь
А с каких пор блокировка макросов мешает работе с документами? Просто макросы не будут запускаться, и всё.
А что угодно в документе творить можно и дальше.
Да и блокировка макросов возможна как полная, так и частичная — блокировать только неподписанные.
Похоже, пришло время запрещать: Запретить использование командной строки(Конфигурация пользователя — Административные шаблоны — Система в gpedit.msc)
Не нашел, как решен вопрос PowerShell Execution Policy?
powershell.exe запускается с ключем -executionplicy bypass. На втором скриншоте это видно
А вот тут большая пребольшая дыра походу.
И так — имеется ПК в домене + учетка которой через GPO запрещено выполнение любых программ кроме списка явно обозначенных (cmd в нем есть а вот powershell нету).
Попытка запуска powershell через ярлык или как-то еще ни к чему не приводит.
Но вот если мы запустим cmd и там набирем "powershell -executionpolicy bypass" — то мы окажемся в среде powershell и выполнив "Get-executionPolicy" убедимся что режим реально стал bypass, хотя по умолчанию выполнение скриптов было запрещено.
Вот такая вот фигня.
Никакой дыры, если у нас есть возможность заставить cmd выполнять произвольные команды, почему выполнение powershell скриптов это что-то более опасное?
Я правильно его запускаю?

Тут на днях случайно наткнулся на ещё один вариант "вируса на powershell" на StackOwerflow. Способ заражения неизестен, но механизм работы занятный.
То есть тот факт, что в описанном мной примере изначально пользователю запрещен запуск powershell в принципе, но из cmd оно таки запускается и в дополнение к этому совершенно спокойно происходит смена политики выполнения этих самых скриптов это нормальная ситуация?
Отвечу на оба каммента сразу:
происходит смена политик
Нет, не просиходит. Запускается отдельно взятый инстанс процесса powershell в обход политики. Вы можете это воспринимать это как одно и то же, но на самом деле это не так. Кроме того, много раз Майкрософтом было сказано, что execution policy — метод защиты от случайных запусков скриптов, с безопасностью он имеет мало общего
запрещено выполнение любых программ кроме списка явно обозначенных (cmd в нем есть а вот powershell нету).
Откройте cmd и вызовите из него любую программу не из "списка явно обозначенных". Удивление гарантирую :) Скажу даже больше: почти все утилиты (ping, ipconfig, netsh) — точно такие же экзешники, как и powershell.exe. Можете легко найти их поиском в системной папке.
А вот тут большая пребольшая дыра походу.
В вызове powershell через cmd нет какой-то секретной магии. Он запустится в контексте тех прав, с которыми выполнялся cmd. А значит сможет сделать ровно то же, что и так можно сделать через cmd и bat-файлы.
А как бороться-то? В гугле пока пусто.

— запрещать вообще (или только неподписанные) макросы
— запрещать cmd для всех без прав админа — Как это отразится на логон/логофф скриптах
https://community.spiceworks.com/topic/430295-disable-cmd-for-all-users-but-administrators
http://stackoverflow.com/questions/29699337/disable-cmd-and-powershell-on-windows-server-2012-for-clients
Дырка же в том, что пользователь может включить макросы. Какая разница, будет зловредный код написан на VBA или на powershell?
С CMD как бороться не в курсе, а с PowerShell довольно просто. Назначать ExecutionPolicy в 'AllSigned' через GPO. В таком случае '-ExecutionPolicy Bypass' не сработает.
Пример

Не помню навскидку — режит AllSigned требует только своих внутренних сертификатов, или скрипт может быть подписан левой подписью и таки отработать???
Должно быть подписано доверенным валидным сертификатом.
Отлично, действительно работает.
Капец конечно, запуск через CMD даже спокойно обходит ограничение в прямом виде через SRP )))

Интересно, это не повлияет на запуск всяких встроенных maintenance скриптов в task sheduler на новых системах, там вроде было что-то встроенное, с запуском по расписанию??
Это не работает для однострочников, да и подписывать свои скрипты ленится даже Microsoft (последний абзац).

Это работает для любых *.ps1 файлов.
Для powershell.exe -command "<command here>" оно, действительно, не сработает. Впрочем, даже в EncodedCommand особо много не запихнуть (функция шифрования, например, не влезет), так что я бы не переживал сильно на этот счёт.


Я говорю про защиту от выполнения именно сторонних неподписанных файлов-скриптов.
Ну а то, что кто-то не подписывает какие-то конкретные скрипты — так кто мешает подписать внутренним сертификатом, если уверен в скрипте? <paranoia mode>Я вот, например, никогда не уверен в левых скриптах и перепроверяю сам, кто бы их ни написал.</paranoia mode>

Зарегистрируйтесь на Хабре, чтобы оставить комментарий