Avanguard: The Win32 Anti-Intrusion Library

HoShiMin,

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

Да, вот пример https://yadi.sk/i/qIDXlVbjQQM9WQ
Сервисные параметры накапливаются в буферах и выборка в исходные области не происходит. Появился и первый косях при тестах - в одной из версий ос происходило обращение сразу к двум областям. Я уже в ядро полез искать как такое возможно.. оказалось это авер avg из своих кривых хуков в сст память трогает, от них всегда проблемы.

 

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

Реализовано наследование указателей, при отладке всё работает стабильно, как запланировано.

Я уже описывал решение по OP, то же самое наследование необходимо и для реализации нт-анклавов.

 

стареешь... это нормально...

 

Rel,

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

 

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

На самом деле, ты меня уже убедил, что визор - классная вещь, вопрос только в целесообразности и времени на реализацию. У меня висят ещё и другие проекты - гипервизор для VT-x и скрытные хуки в юзермоде и ядре, доработка минифильтра, чтобы соответствовать требованиям Verifier'а (оказалось, что он ругается на IoVolumeDeviceToDosName в PreCreate, и вот что хочешь с этим - то и делай), не считая совершенно отвлечённых проектов на джаве (которые и делаю не для себя).

В общем, я бы с радостью попробовал всё, но нет столько времени.

 

HoShiMin,

> Как ты и говорил, защита от инжектов, против которых я ставлю фильтры - не задача визора

Я бы давно это крутнул под dye, если бы был твой рабочий билд. Никакую новую инфу из этого мы не получим.

> требованиям Verifier'а

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

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

Кстате думаю это будет 5-й публикацией по выборке, именно этой части не хватает для полной картины.

 

В юзермоде ещё ладно, а в ядре, всё же, стоит довериться ему. По крайней мере, я хотя бы буду уверен, что ничего нигде не утекает, все хэндлы закрыты, ссылки задереференсены и в фильтрах не происходит ничего неожиданного. Заморачиваюсь с валидностью (особенно, учитывая качество кода паблик-драйверов на unknowncheats, где ридонли-память делают записываемой, сбрасывая WP-флажок!).

А про какие публикации ты говоришь? Ты где-то пишешь и выкладываешь статьи?

 

HoShiMin,

> Ты где-то пишешь и выкладываешь статьи?

Вот же новость, да https://wasm.in/blogs/author/indy_.17347/

Эта тема заканчивается на наследовании выборки. Хотя это всё к вашей теме имеет лишь косвенное отношение.

 

Ждем. В моем окружении людей способных на подобный полет мысли нет, и думаю не только в моем.

 

Indy_
Почитал статьи - в общих чертах (в общих!) примерно так визоры и представлял, но в деталях видна огромная работа.
В любом случае, чтобы въехать в тему и говорить предметно, надо брать и писать свою реализацию хотя бы самого простого визора-эмулятора, который сумеет выполнить некий поток инструкций, и дальше уже двигаться в сторону защиты памяти.
Когда появится время, попробую написать нечто подобное, но вопрос о времени и целесообразности остаётся открытым. Если не секрет, сколько по времени заняла реализация простейшего визора и какие задачи решала? И достаточно праздный вопрос, Indy_, почему ты взялся за этот проект? Это была необходимость (например, по работе) или из интереса реализовать подобное? Помню, что ещё года два-три назад ты занимался визорами - очень долгоживущий проект.

 

HoShiMin,

Все основные задачи к этому приводят, это их решение. К примеру скрытие памяти от сканера ав или защита от OP.

Защита памяти - в конечном варианте памяти быть не должно, образ или всё АП N/A. Оно всё является анклавом, а данные дешифруются при их выборке. Тогда удалённо, из иного процесса, режима(ядра) или не доверенному потоку прочитать память нельзя. А для этого нужно решить две задачи - контролировать выборку на уровне декодера инструкций и решить проблему с сервисной выборкой.

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

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

HoShiMin,

Я раньше не брался за сервисную обработку(наследование указателей), думал что это решить нельзя, да и в целом тема стрёмная. Но получилось что это весьма просто и работает стабильно. Не ясно что делать с разложением указателя на компоненты(eg: mov ah,cl; ecx:PTR). Но обычно в апп это не используется, только в отморфленном коде или при виртуализации. Маркируя память можно получить лог по указателям(источник их). Тогда все сервисные аргументы(прототип) определены и выборки в целевую область нет, так как указатели туда определены. Только лишь так можно убрать область памяти что бы не сломать апп.

 

galenkane, ты чего разошёлся?

 

HoShiMin, вижу в вас божество

 

Недостатком ЧСВ не страдаю, но не в таких масштабах)

 

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

Чем жестче диктатура, тем меньше свободы и возможностей.

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

Печально смотреть на код, который используя импортируемые ring3 процедуры пытается что-то защищать. Какой смысл в этом гуане, если инжект отработал в процесс ранее запуска этой всей шляпы и его даже не видно, потому как он выглядит легитимным? Ты добавляешь списки, где определяется, что может работать, а что не может. Доверять с ровного места на скомпрометированой системе глупо, никаких белых списков областей памяти, потоков и пр. быть не должно в принципе. Задача нерешаемая для системы в которой нет субъектности у областей, потоков и пр.

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

 

im.
Честно говоря, не понял сути претензий. Давай по пунктам.

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

> на скомпрометированной
А что это значит? Считается ли машина пользователя, который сам и будет инжектить, скомпрометированной? Допустим, считается. При этом, мы не хотим, чтобы пользователь в нас что-то инжектил. Что делать?

А что плохого в именно ring3? Что не в ring3 можно сделать такого, что нельзя в ring3? Проблема не в том, чтобы железобетонно защититься от инжектов всего на свете, а в том, чтобы при этом не поломать совместимость с самой системой, антивирусами и драйверами, которые должны иметь возможность инжектиться и перехватывать функции беспрепятственно.

А это уже абстрактная демагогия, потому что понятия "справедливее" и "честнее" для каждого свои, как и мнение насчёт эксплуатируемости одних людей другими людьми.

В огороде бузина, в Киеве дядька. Начали про NT, закончили экзистенциальным упадническим настроением.
Правильнее для чего? Либа свою работы выполняет? Выполняет. Методы обхода есть? Разумеется, есть. Стал ли порог вхождения в инжекты чуть выше? Стал. Помогает ли либа детектить инжекты через паблик-инжекторы, типа Xenos/ExtremeInjector? Помогает. Тогда какие могут быть претензии?

 

Zenadriver? гугл молчит

 

HoShiMin, если приложение имеет низкие права и low integrity, то никакие инжекты оно сделать не сможет, а в новой модели безопасности win10 охватывается и обратная ситуация, что в приложение с низкими права можно закрыть доступ. Вот это работает железобетонно. Какой толк твоих поделок? Это как успевать вычерпывать воду из дырявой лодки.

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

Я тебе напомню такую вещь, как перехват SSDT практиковавшийся всеми гуано АВ на свете, какое-то время назад. В результате чего потребовалось взять под контроль ядро, ибо все эти вмешательства работали криво. Что мы имеем сегодня. Имеем то, что документированные возможности ОС и свободу действий какой-то поц с форума решил поставить под сомнение и написал типа "секьюрити либу". Логика такая же как у аверских контор. Идея собственно не нова, ибо уже есть всякая хренота как rapport и прочее, которое обламывалось каждый раз по воздействию на управляющие мютексы/ивенты/потоки. Надежность твоего решения обеспечивается за счет подхода обскьюрити, т.е. пока его никто не знает оно как-бы работает, но когда будет использоваться повсеместно, то появятся решения прибивающие на ходу эту шляпу.

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

--- Сообщение объединено, 28 май 2019 ---

https://code.google.com/archive/p/ontl/downloads

 

im.
Смотри: пользователь запускает приложение под учёткой с ограниченными правами, запускает инжектор с правами админа, инжектит дллку любыми способами. Ни один из предложенных тобой способов не сработает.
Идём дальше: пишу драйвер, ставлю минифильтр на фс, ставлю Ps-каллбэки на загрузку модулей. И? Что мне это даст? Ты говоришь "валидировать". Хорошо: пользователь запускает драйвер и мануалмапит либу в процесс. И чем тут поможет фильтрация запуска процессов? Запрещать загрузку любых неизвестных мне драйверов и сломать систему?
Ты предлагаешь что-то концептуально, может, и правильное, но неосуществимое и неприменимое в продакшне, далёкое от реальности.

 

Пользователь с правами админа... Это уже кривоватая архитектура, не кажется?
Что касается остального https://docs.microsoft.com/en-us/wi...mitigations-in-windows-10#protected-processes

Что касается валидации. Отсутствие запрета на запуск непойми чего ведет к запуску непойми чего. Решение описанное в топике это вообще фейспалм. Детектинг по ФАКТУ инжекта, поиск признаков вторжения непосредственно в защищаемый процесс. Это как ходить по охраняемому объекту и искать следы пребывания вторгшихся... Тут надо как-то переименовать софту что ли, что-то вроде intrusion analyzer или kid-injects-detector.