Avanguard: The Win32 Anti-Intrusion Library

Именно от них, потому что именно эти инжекты и будут использовать для внедрения своих библиотек.
Просто абстрагируемся от деталей и подумаем: много ли вообще людей представляют, как собрать цепочку гаджетов, чтобы выполнить нужный код? Да таких единицы процентов по соотношению с остальной массой кодеров, которые просто возьмут ExtremeInjector, даже не представляя, как он работает внутри. Вот почему я говорю лишь о достаточной защите. Потому что именно штатные инжекты в лабораторных условиях и используются в "широком продакшне".

--- Сообщение объединено, 20 мар 2019 ---

Я ничуть не умаляю необходимость визора для защиты от перехвата потока команд, но банальный пример: ставят SetWindowsHookEx - и что дальше? Оконный поток сам же и побежит загружать либу, совершенно легитимно. Визор в данном случае полезен как защита для защиты, чтобы не сняли фильтры, но фундамент - именно фильтры на точках входа (а в случае контекстов, точках выхода) инжектов.

 

HoShiMin,

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

 

Хм, не совсем понял.

Приведу реальный пример: процесс джавы. В него инжектят дллку (любыми способами), она аттачит поток к JVM и получает возможность работать с виртуалкой через интерфейсы JNI/JVMTI (набор нативных функций в JVM для управления поведением виртуалки). После этого подгружают джава-класс специальной функцией JVM_DefineClass.
Нам нужно любыми способами предотвратить загрузку джава-класса в виртуалку.
Используемые инструменты для внедрения дллки - инжектор в ProcessHacker'e (пока его не вырезали), пресловутый ExtremeInjector, довольно часто AppInit_DLLs, чуть пореже - SetWindowsHookEx. Чрезвычайно редко - апц и контексты. И ни разу я не видел, чтобы кто-то использовал какой-нибудь ROP, чтобы сделать то же самое. Вот и пример, где используются штатные инжекты в лабораторных условиях. И что в таких случаях делать?

Здесь не банковский софт, на внедрение в который тратятся квинтиллионы долларов и все возможные виды атак, включая аппаратные. Здесь самые банальные, затёртые до дыр книжные академические инжекты дллок.

 

HoShiMin,

> Хм, не совсем понял.

Так как доступ к уже созданному процессу как то ограничен, то создаётся клон процесса, на что нужны меньшие права. Обычно там окружение процесса не запускается, а проецируются свои образы и запускаются. Это классический путь запуска малвари.

 

В том и дело, что нет. Пользователь может запустить процесс с ограниченными правами, работая под учёткой хоть NT_AUTHORITY/System. Он может делать с процессом совершенно всё, что пожелает (ObRegisterCallback пока не рассматриваем), поэтому и не требуются настолько изощрённые методы внедрения.

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

--- Сообщение объединено, 21 мар 2019 ---

Это я к тому, что зачем извращаться с лоадерами и прочим, если достаточно прописать дллку в AppInit_DLLs, и процесс сам её подгрузит?

 

HoShiMin,

Это всё на мой взгляд обсуждение по типу сам защиту придумал сам обошёл и так рекурсивно. Против лома нет приёма, если нет другого лома. Это просто смысла не имеет.
Как уже говорил защита должна блокировать обратные атаки. А эти инжекты - открыл процесс и setcontext/queueapc/etc это тут в виде обучалок. Я не помню даже когда последний раз такое видел.

 

Тут ещё зависит от сферы, в которой работает защищаемое приложение, есть ли физический доступ к машинке с ним и т.д.
В моём случае приложение работает на машинке пользователя, он может делать с ним что угодно, и в таких условиях я просто не вижу смысла городить огород с контекстами (не говоря уже про обратные атаки), если банальный CreateRemoteThread(LoadLibrary) сделает всё необходимое.

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

 

superakira,

Принципиальной разницы между 86-64 никакой нет, все механизмы и алгоритмы теже самые. Даже на 86 отладка заняла очень много времени(большая часть ошибок трудно разбираема, так как из за не корректной обработки событие получается отложенным; к примеру инструкция не верно декодирована и после тысяч итераций возникнет проблема, которую трудно выявить), стрёмно подумать даже как это будет на 64..

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

К примеру задачу по поиску EP, которая на кл я так и не решил, точнее я к ней не возвращался. Так как нужно серьёзно покодить, реализовав тот самый граф указателей(PFG), который нужен для защиты от OP. Это довольно сложная задача. Когда это напишу, тогда вернусь к нескольким задачам, в частности и по OP.

 

Новость. Реализовать нт анклав в юм возможно. Это значит что можно протектить всё. Я покажу если получится.

 

Гут, ждём

 

HoShiMin,

Возможен сервисный перезапуск. Это сложно, но сам механизм следующий. У сервиса есть прототип, в нём указатели. Тут проблема первая определить что значение указатель. Наследование требует слишком много памяти(1/8 АП).
Структуры растут вниз(такое использовалось RLDE).
Выборка доступна из юм - #GP(сторожевые страницы). Тогда у сервиса есть прототип, части которого растут вниз во множестве пограничных областей. Это позволяет определить указатели и размеры структур. Но это значительная работа, так будет множество скрытых нюансов.
Таким же путём можно определить число сервисных параметров(уже практически проверено), это работает.

 

в венде есть встроенные интерпретаторы JScript и VBScript, загружаемые и расширяемые через COM, гуглить на тему интерфейса IActiveScriptHost...

 

Indy_, честно говоря, не понял ничего. Какой сервис? Что такое "сервисный перезапуск"? Какие указатели? Где "в нём"? Почему нужно определять, что значение - указатель? От чего наследование и зачем? Какие структуры растут вниз? Что такое RLDE?

Что конкретно нужно сделать, чтобы доступ к заданному участку памяти имел только процесс\поток? Судя по #GP, ставим на страницу PAGE_GUARD (или вообще страницы нет в памяти или она лежит в другом месте и\или сжата\закриптована), а при обращении кода к ней ловим эксепшн и подкачиваем страницу с диска или меняем права на R/W, если к странице обращается доверенный поток. Правильно понимаю? Или какая вообще идеология этих анклавов? Если идея верная - то VirtualProtectEx/Read[Write]ProcessMemory сработает без проблем, если страница физически загружена в процесс

Гут, гляну

 

Мощная штука! Проверил парочку км-инжекторов, ни один не справился.

 

а отладчиком windbg можно приатачица к защищенному процессу в invasive/noninvasive режимах отладчика?

 

Антиотладку ещё не встраивал, можно

 

HoShiMin,

> Судя по #GP, ставим на страницу PAGE_GUARD

Если сервис обратится к невалид области памяти, по произойдёт ошибка. Выборка не контролируется в другом режиме. Тогда нужно знать все указатели и размеры структур в сервисных параметрах. Это можно сделать через сторожевые страницы. Каждый указатель из параметров сервиса устанавливается на границу страницы RW-GUARD и сервис запускается. Он возвращает #GUARD_PAGE_VIOLAT. и определить куда произошло обращение можно по снятому атрибуту GUARD. Тогда блок данных связанный с указателем смещается вниз на один байт и сервис перезапускается. Так определяется размер текущей структуры по указателю, разумеется они могут быть вложенными. Основная проблема это проверка указателей, так как нельзя изменять в параметрах сервиса не указатели. При такой реализации можно полностью область(нп секцию или образ) удалить из памяти.

 

Теперь понял. Уже пробовал сделать концепт?

 

Глядя на исходный код, не могу придумать, как из под юзверя это дело обойти без атаки на сам античит... Чисто теоретически, смена контекста в режиме ядра должна сработать же ?

 

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

--- Сообщение объединено, 18 апр 2019 ---

Пример шелла, который сработает и не спалится сам по себе, пока из него не вызовут функцию, на которой стоит проверка стактрейса (NtContinue, NtSetContextThread, LdrLoadDll):
https://github.com/HoShiMin/Avanguard/blob/master/AvnSample/AvnSample.cpp#L70-L374

--- Сообщение объединено, 18 апр 2019 ---

И на очереди проверка адресного пространства по таймеру на предмет регионов памяти, которые мы не выделяли