Comments 46
не положенном для исполняемых файлов месте: папка "загрузки", temp, съемные носители, etc
С недоступным для исполнения temp будет невозможно запустить DISM или установить софт, установщик которого распаковывается в temp и запускается оттуда.
А потом вы посмотрите на права в куче папок и узнаете, что внутри C:\Windows есть такие места куда пользователь без прав может что-то положить и выполнить, а если еще поковыряться, то даже можно найти места которые в которые можно писать и исполнять, но нельзя читать.
Пока не успели взгрустнуть читаете о lolbin'ах. Вот тут унываете совсем.
А потом еще узнаете про веселые особенности, типа альтернативных файловых потоков и просто забиваете на все попытки ограничить пользователей. Поскольку реальной проблемы запреты не решают.
Именно из-за такого подхода - "забить на попытки ограничить" - и были все те нашумевшие случаи с шифровальщиками-вымогателями. Вирус запускался не из особых мест или альтернативных потоков, а был просто распакован из архива в письме и запущен тупо из temp! Делаем выводы.
Следуя такой логике можно вообще ничего не делать (накрыться простынёй и ползти на кладбище). SRP и AppLocker - один из рубежей обороны, при том достаточно эффективный.
Чем больше тех, кто ставит защитой SRP, AppLocker или WDAC, тем проще мне работать на пентестах, спасибо вам.
Напишите статью - поделитесь знаниями чем SRP/AppLocker помогают Вам в пентестах. Я имею в виду почему с ними становится хуже чем без них. Все только спасибо скажут. Кто был не прав - сделают выводы (возможно я ошибаюсь?).
Вы переоцениваете смысл такой статьи.
На аргумент вида "но выглядит же закрыто/безопасно" мне сказать нечего. Но и как "открыть" такую дверь вопросов тоже не вызывает.
Нет, это выглядит так: "У этой технологии есть недостатки, поэтому использовать её не надо/бесполезно". При этом не существует ни одной технологии, которая даёт абсолютную безопасность. В т.ч. тогда бы не нужны были пентестеры - просто делай так-то и ты в абсолютной безопасности.
Данная технология может и должна использоваться в комплексе с другими.
Ну вроде не хуже, чем вообще без, даже по картинке. Уже случайная мышка, птичка или даже кошка не зайдет. Или что вы хотели сказать?
Sysinternals GPdisable или тот же GPCul8or обходят эти ограничения ещё со времён той самой Windows XP
Чтобы запустить что-то обходящее ограничения ГП, нужно запустить исполняемый файл вне положенных мест. Замкнутый круг. Разорвать который можно только документом с эксплойтом.
Советую ознакомиться с принципом работы, не требуется ни эксплоит ни запуск вне положенного места.
Принцип работы: Gpdisable.exe c:\windows\explorer.exe
Как я запущу Gpdisable.exe, если ГП запрещает мне его запустить в том месте, куда я его имею возможность сохранить? И потом, речь идет не о хитром сотруднике с хакерскими наклонностями, а о вирусе, который должен быть сначала запущен, прежде чем предпринимать какие-то хитрые действия по обходу ГП.
Принцип работы - инжектирование dll. То, что вы описываете - просто надстройка для домохозяек. Реальный пример использования:
Переименовываем gpdisable.dll в ehTrace.dll
Создаем папку с именем anything.{2E095DD0-AF56-47E4-A099-EAC038DECC24}
Кидаем ehTrace.dll в только что созданную папку
Заходим в папку и создаем там любой документ в Word, Excel или, к примеру, PDF’ку
Открываем только что созданный файл
Соответствующая программа должна запуститься и запустить вместе с собой подгруженную DLL
Никакие запускаемые файлы в этом методе не используются. И это лишь один из множества аналогичных способов.
Не работает. Проверено на word, wordpad, pdf + Adobe reader под Win7 32bit, запускаю даже проги из окна открытия файла - результат один: "заблокировано администратором". Как можно еще помочь вирусам запуститься? Кстати про инжектирование dll - а я еще дополнительно поставлю в окне "применение" - "для всех файлов" (включая DLL) Всё, тупик?
Вот ещё 7 вариантов, экспериментируйте на здоровье. И даже это не полный список.
Кучу софта ставится в профиль пользователя - да что греха таить, сам такой пишу. Потому что подобный подход резко сокращает время на деплой релиза: переустановка с правами админа это долго, бюрократично и так далее, особенно когда клиентов много разношерстных - когда как автообновление в папке пользователя происходит вообще незаметно. Вирусописатели про эту фичу знают, потому вирусы устанавливают себя туда же, в профиль... Тут и сказочке конец, закрыть папки профиля на исполнение нельзя, сломается куча софта.
Плюс большинство шифровальщиков вообще не закрепляются в системе - они стартанули через уязвимость сразу из оперативки, причем в контексте процесса-донора, отработали, исчезли. Им не нужно привлекать к себе внимание.
Вот за такое руки отрывать надо (извините - ничего личного). Т.е. вы прекрасно понимая, что делаете не правильно все равно продолжаете это делать т.к. это "резко сокращает время на деплой релиза", "бюрократично и так далее". Вставляя палки в колёса сисадминов, которые внедряют SRP/AppLocker, прекрасно при этом понимая, что вирусописатели этим пользуются.
Я еще могу понять если софт пишется для домашнего сегмента. Но если это софт для корпов, то это крайне печально. Например тот же Chrome имеет "домашний" инсталлятор, который ставит его в профиль и "корпоративный" в виде .msi, который ставит по всем правилам в %ProgramFiles%.
В список грехов можно добавить:
Складывание кэша и прочих временных файлов в %APPDATA% (ломает концепцию перемещаемых профилей).
Использование захардкоженных путей вместо переменных окружения.
Пример. 240+ клиентов. У кого-то есть средства администрирования, у кого-то админы бегают ручками ставят на тысячи компов (условно), у кого-то админский доступ надо заказывать за месяц у СБ... Выпускаешь релиз и ад у поддержки начался - "ой а у нас нет обещаной кнопочки" - "вы обновились?" - "а мы не можем, согласовывать установку месяц... Но кнопочка нужна, я пошел эскалировать вопрос вашему гене, делайте как хотите без админа..." Дальше вой, рыдания, скандал, ругань, злые отзывы, 9000 звонков на поддержку, задалбывание руководства этими заказчиками.
Магазина приложений на виндах нет - то, что есть, убогое, и в корпоративной среде сразу вырезается. Иного канала распространения софта нет - скачивай по ссылке инсталлятор и от админа переустанавливай, каждый апдейт, а они частые. Либо заводи сервис, который всегда работает от системной учетки и мониторит обновы, но на это многие СБ высказывают свое недовольство. У трех четвертей заказчиков нет системы массового деплоя софта (или доступ зарегулирован бюрократией так, что формально есть, фактически нет), всё ручками - это данность, с которой надо уметь жить.
Именно потому всякие дискорды и прочие часто обновляемые приложения встают в профиль - иных вариантов доставить частые обновы и не достать пользователя, нет.
Почему Вы так делаете я прекрасно понимаю, тут мне объяснять не надо. А знаете почему так всё происходит? Потому что им тоже так удобнее - удобнее отобрать права админа и не иметь при этом средств администрирования, удобнее не иметь дежурного админа который всегда на связи, удобнее иметь безопасников-самодуров и много что еще удобнее. Неудобно потом выкуп за файлы платить только.
Дело в том, что сисадмин и разработчик софта (софта для бизнеса если точнее) работают не для того что бы было как им удобнее, а для того что бы бизнес эффективно работал и зарабатывал деньги. В том числе деньги на их зарплату. Эффективность это в том числе наименьшая уязвимость к всевозможным атакам. Есть правила написания софта под определённую ОС и практики её администрирования. Если бы все придерживались их, то и проблем бы не было.
Вы мне поделились своей болью со стороны разработчика, а я Вам со стороны админа, который потом это обслуживает.
Но однако я привёл в пример Chrome, который эту проблему решил достаточно изящно. И это не единственное ПО, которое пользуется таким подходом (два разных инсталлятора). Подумайте над этим, прошу как админ.
PS Впрочем такой софт на самом деле не ломает под ноль использование SRP/Applocker. Там можно настраивать довольно гибкие исключения, в т.ч. по сертификату подписи и хэшу исполняемого файла. Определённые неудобства вызывает, но не критично.
Занимаетесь выпуском частых обновлений = занимаетесь ИБД
Предлагаю сказать так заказчикам, которые просят эти обновы :)
Никто от себя фичи не пилит - это не всем известный банк, где в приложении сторисы, видосы, и прочий мусор. Здесь все фичи - реквесты со стороны клиента.
Во всей остальной жизни - выпускают обновления ради обновлений, сами растрачивают деньги на ораву программистов выпуск новых версий как из пулемета, пользователей мучают, навязывая им новые версии. Даже когда новых фич по сути не добавляется, даже когда продукт бесплатный - браузеры, линуксы, месснджеры. Зачем тратить больше на пулеметный CI/CD конвейер, когда можно тратить меньше? Но с маниакальным рвением - тратят!
У меня нет и не предвидится той кучи софта, что ставится в профиль пользователя. Но на такой особый случай - в статье как раз был пункт про добавление в белый список запускаемого из сетевой шары софта. Да, проблема решается именно так: на сервере установлено и обновляется когда надо, а папка хардлинком смотрит в шару. Автообновления вообще зло, каждое поделие лезет обновляться, замедляет работу. Вычищаю скриптом все автозагрузки во всей сети - и порядок!
Плюс большинство шифровальщиков вообще не закрепляются в системе - они стартанули через уязвимость сразу из оперативки, причем в контексте процесса-донора, отработали, исчезли. Им не нужно привлекать к себе внимание.
А как же заблокировать экран надписью с вымогательством денег? Иначе смысл было шифровать? Большинству шифровальщиков как раз таки нужно закрепляться в системе и привлекать к себе внимание, требуя выкуп.
А они двухэтажные, "невидимая" часть, что закрепляется и исполняется в системе, реализует шифрование данных и размножение при зашифрованых данных файла-stub-а (костыля), который только сообщает требования, и при себе ничего уже не содержит. Причём его взять в виде типовых стабов - "данный файл не работает в данной системе" :) ...
Таким образом можно скрыть все следы и оставить необходимые контактные данные.
В комментах жду решения как убрать исполняемый атрибут для новопримонтированных файловых систем.
Нет необходимости трогать атрибуты. Достаточно монтировать с опцией noexec. См. конфиги udisks2, если дистрибутив на базе debian.
Смотрел, не влияет на exec bit при автомонтировании новой ФС. Есть пример конфига, который успешно отключил установку exec bit?
Просто атрибут монтирования noexec не даёт прямо запускаться, т.е. файлы нужно запустить или с другого места или с другими танцами и плясками, погрузкой модулями. Но это также перекрывается LSM модулями, сиречь SeLinux, AppArmor, RSBAC и прочими, уже ушедшими в историю.
Exec-биты у файлов никуда не денутся. Просто запуск не будет работать. В том числе из под рута, поэтому ни в коем случае не стоит перемонтировать / c noexec :-)
В догонку к закручиванию гаек - опции nosuid и nodev
А там просто совершенно не пуганная из-за отсутствия вирусов публика.
Оставлю это здесь.
Скачал вирусов себе на линух.
Распаковал. Поставил под root. Не завелись. Два часа гуглил, оказалось, вместо /usr/local/bin вирусы стали в папку /usr/bin на которую у юзера malware нет прав на запись, поэтому вирус не может создать файл процесса. Нашел на китайском сайте патченый .configure и .make, пересобрал, переустановил.Вирус заявил, что ему необходима библиотека cmalw-lib-2.0. Оказалось cmalw-lib-2.0 идет под CentOS, а под убунту ее не было. Гуглил два часа, нашел инструкцию как собрать .deb пакет либы из исходников. Собрал, поставил, вирус радостно запустился, пискнул в спикер и сделал core dump.
Час чтения syslog показал, что вирус думал, что у меня ext4 и вызывал ее api для шифрования диска. В btrfs это api deprecated поэтому линукс, заметив это непотребство, перевел раздел в рид-онли.
В сердцах открыл исходники вируса, grep'нул bitcoin кошелек, отправил туда $5 из жалости и пошел спать...
И детская болезнь винды с предложением что-то автозапустить при вставлении флэшки.
Никогда такого не встречал за свою многолетнюю практику с Линуксом. ЧЯДНТ?
Большое разнообразие всевозможных дистрибутивов и их версий с одной стороны спасает, с другой - коммерческое ПО точат под конкретную компанию и версию (например RHEL 5) и поддержка зоопарка не предвидится. Другим нужно искать ршел или деривативы или ставить контейнеры, сиречь все эти flatpack-и или докеры.
Большое разнообразие всевозможных дистрибутивов и их версий с одной стороны спасает,
Понятно же, что если кто-то очень захочет навредить кому-то конкретно, то он это сделает и в Линуксе. Никто не спорит, что типа в Линуксе не может быть зловредов и дырок, но дело вовсе не в разнообразии дистрибутивов(хотя и в этом тоже), а в самом подходе - по умолчанию, все закрыто и огорожено. Тебе надо, ты и открывай. В отличие от форточек, где, как говорил М.М.Жванецкий, "любое неосторожное движение и ты отец". Поэтому ни о какой эпидемии шифровальщиков в пингвинятнике не может быть и речи. Так, ОРЗ, легкий насморк. И жизнь(практика) это отлично подтверждает. Аргумент, что никто не пишет массово зловреды под Линукс из-за того, что его в мире только 3-4%, не катит. Так себе аргумент. Слышу его уже лет цать. Если в начале он имел основания, то сейчас нет. Никсов в жизни, гораздо более 3-4%. Не пора ли уже закопать эту стюардессу(Винду) Windows must die.
С закрытием по умолчанию дистрибутивы типа убунты боятся, отчего становится опасно. Что касается ограничений, здесь также как и виндах есть множество ошибок, а зачастую и специально внедрённых дырок, как обнаруженная в этом году дырка в виде блоб-а в libz?/zlib? и нацеленная на ssh.
И ранее чудики с одного американского университета, чисто исследовать :))) , вносили намеренно дырки.
А кроссплатформенной ПО как САПРы, или те же браузеры с офисом... Это тоже большое множество векторов атаки на системы, так как в них встроены скриптовые системы с языками программирования.
Те же майки неплохо заморочились и теперь периода полураспада системы раз в квартал, как в 90е уже нет, хотя в свою очередь перегрузили системы шпионскими и рекламными модулями, но это проблема пользователей.
Вредоносов, говорите, нет? В метку флешки пишем some`rm -rf /home`thing, вставляем, упс - скрипты автомонтирования чаще всего не ожидают подвоха, и попытаются выполнить команду внутри строки :) А сколько по этому же вектору атаки открытий чудных даст использование юникода...
Вредоносов, говорите, нет?
Я вижу, что писать то вы умеете, вот только читать, нет. Ну ка, ткните носом, где я такое говорил?
В метку флешки пишем some
rm -rf /homething, вставляем, упс - скрипты
автомонтирования чаще всего не ожидают подвоха, и попытаются выполнить
команду внутри строки :)
Типа албанский вирус? Удалить содержимое домашней директории. На мелкое хулиганство потянет конечно. Провел следственный эксперимент на LiveCD Mint 21.3 и... Упс1. Не выходит каменный цветок.
Во первых, еле нашел подходящую файловую систему(btrfs) для форматирования флешки, которая позволяет ввести длинную метку, чтобы вся ваша "зловредная" команда туда уместилась. Большинство ходовых fs в gparted, не позволяет ввести в метку более 11-16 чаров. Длиннее чем 16 чаров для ext4 не получится ввести, а для всяких там exfat и того меньше, хотя я конечно допускаю, что есть такой способ или тулза, которая позволяет указать длинную метку, но мне такое неведомо. Мамкины хацкеры будут заморачиваться ради мелкого пакостничества. Наверное. А потом хвастаться в классе. Поэтому Упс2. Ваша команда целиком не умещается, но btrfs и NTFS пойдут, в них позволяется длинная метка. Отформатировал флешку в btrfs, завел вашу метку. Отмонтировал флешку. Вынул. Вставил. Ничего. Флешка примонтировалась сама. Домашняя директория цела и невредима. Попробовал в NTFS. Тот же результат. Все было по умолчанию. Я специально не упарывался безопасностью и ничего специально не огораживал. ЧЯДНТ? Скриншоты доказательств я сделал, но не нашел как их вставить в коммент, а выкладывать куда-то и приводить ссылки, мне откровенно лень. Не обессудьте. Отвечать часто не могу, т.к. всякие пи@ор нехорошие люди загнобили мне карму.
Во вторых. Еще с малого детства людей приучают к гигиене, воспитывают не хватать с пола и пихать в рот лишь бы что. Я в здравом уме не буду сам втыкать незнакомые мне флешки в свою систему. А если уж такое случилось, то они ССЗБ. Это уже не техническая проблема и не решается выбором OS. А с дуру можно себе и хуй сломать.
На линуксе у нас народ только рекламные аддоны для браузеров ловил. Скачать и запустить программу для большинства юзеров было сложно в силу неудобства подобного процесса - надо же было ещё на скачанное исполняемый бит поставить.
Но это было давно. Сегодняшний линукс заметно проще в данном плане, скачанное уже просто двойным кликом запускать можно (у меня steamos), потому вероятность запустить таким методом что-то вредоносное имеется. Спасает только то, что оно никому не нужно пока что. Площадями выгоднее виндовых юзеров обрабатывать.
Для запуска Autocad потребуется добавить ещё и C:\ProgramData
Интересная оговорка. При этом в thrustedpaths добавить путь к легитимным автоматизациям, а к этой папке пользователям права только на чтение, установить secureload в 2, реактором восстанавливать ее в 2 при изменении, при этом файл с реактором добавить в автозагрузку, в этот же файл реактор, который при закрытии Autocad будет восстанавливать его в автозагрузке. И при этом надеяться, что ни у кого не хватит "ума" руками дописать в trustedpaths непосредственно в HKCU путь к папке в которой будет файл с очень-нужной-командой. В этом смысле AutoCAD (RIP) и Нанокад - дыры в безопасности по определению, в которые просто никто не лезет, памятный в узких кругах acad.lsp, который просто размножался - безобидная шутка.
Зачем так сложно? На автокадовские скрипты SRP в стандартной настройке не действует по идее - там расширение только LSP, верно?
Строго говоря, файл скрипта - сценариям команд - scr, и кроме них могут быть выполнены AutoCAD'ом команды из штук 5 типов файлов. Причем, ключевое, выполнены AutoCAD с правами пользователя, который его запустил. А средствами того же AutoLISP можно получить доступ к файловой системе, реестру, и из неочевидного, редактирование чертежей без их графического открытия. А тут уже можно делать с ними все, насколько хватит фантазии. Поэтому это сложно - аналог SRP, но исключительно для AutoCAD и вертикальных решений на его базе, поддерживающих AutoLISP, файлы которого антивирусом игнорируются.
Добавлю ссылку с дополнительными правилами: https://help-dev.ru/50e88dce-ce6a-11eb-889f-005056b9418d.html
и про создание правил в версии Home: https://help-dev.ru/50e89e99-ce6a-11eb-889f-005056b9418d.html
Из личного опыта. Есть машины с активной SRP, на которых установлен антивирус Касперского. Пока там использовался Битдефендер все было хорошо. После определенной даты перешли на Касперского, и в один прекрасный день все машины отказались загружаться.
Детально не разбирался почему (выглядит так, что некоторые обновления антивируса - не баз - запускаются из очень нестандартных мест), просто предупреждаю, что SRP и Касперский - гремучая смесь, которая требует особого внимания.
Когда есть SRP и прочие настройки, мешающие запуску вирусов, такое зло как замедляющий систему антивирус Касперского - больше не нужно! Антивирус становится только последней линией обороны - для подстраховки и поэтому он теперь имеет полное право быть более легковесным. И кстати, в DrWeb есть свой аналог SRP, который более защищенный и гибкий, чем встроенное средство от MS. Опять же - надо догадаться и не постесняться его включить.
Хз что и как у вас. У нас таких проблем не встречалось.
SRP требует порой оч. неочевидных настроек.
Например есть рекомендованные:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%
а есть неочевидные:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData%
За рекомендацию исключать .lnk из контроля я могу также рекомендовать отрывать руки и тестикулы таким рекомендовальщикам.
Поскольку тогда команда cmd /c "del /q /r /f" отрабатывает тихо и спокойно, не нарушая сон пользователя.
Просто настройка SRP в этом месте не очевидна.%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Administrative Tools%/*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Desktop%/*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%/*.lnk
и т.д.
для профиля пользователя
%HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Desktop%/*.lnk
%HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Programs%/*.lnk
Внимательные читатели уже заметилои использование прямого слеша в качестве разделителя частей пути и использование параметров реестра в качестве путей.
Если у вас часто обновляется программа да и ещё в профиле пользователя, то можно прописать путь до каталога установки и имени файла. Это дольше т.к. запускаемых файлов много. Но это потребует филигранной точности при атаке.
Пример для 1С-Connect:%HKEY_CURRENT_USER\Volatile Environment\LOCALAPPDATA%/Programs/Connect Desktop/app/bin/connect.exe
%HKEY_CURRENT_USER\Volatile Environment\LOCALAPPDATA%/Programs/Connect Desktop/app/bin/rda/r*.exe
%HKEY_CURRENT_USER\Volatile Environment\LOCALAPPDATA%/Programs/Connect Desktop/app/bin/updater.exe
Ограниченное использование программ — или шифровальщик