запрет в приложенни remotethread, openprocess

есть приложение А в нем необходимо сделать так чтоб другие программы не могли в него внедрить поток (через remotethread) и открыть процесс(а особенно чтоб не могли вызвать для процесса А writeprocessmemory).

 

есть легальный способ? кроме как хукать NtSystemInformation (кажеться так называеться эта функ))

 

Проверка прав. Только в windows от неё очень мало толку )

 

это как?
приложенни А может как то получить информацию что в него внедрили удаленный поток?

 

это как?
приложенни А может как то получить информацию что в него внедрили удаленный поток?

 

Один из легальных - прицепить dll и ловить там DLL_THREAD_ATTACH

 

С помощью функции SetSecurityInfo() можно выставить для своего процесса такой DACL, который не разрешит другим процессам создавать в нём удалённые потоки. Проблема в том, что если злонамеренный процесс будет запущен с правами хотя бы администратора, то смысла в этой защите не будет, т.к. администраторы во-первых, могут обойти проверку прав доступа, во-вторых, могут переназначить твой DACL. Модель безопасности NT полагается на то, что недоверенный код никогда не будет запущен с административными привилегиями.

Если твоё приложение точно знает, какие потоки оно (прямо или косвенно) создаёт, то не вижу никаких препятствий для того, чтобы перечислить активные потоки и сравнить их с эталонным списком. Второй способ заключается в установке нотификатора на создание потока. Это можно сделать либо в ядре, что предпочтительнее, либо в приложении, написав дополнительно ещё DLL и ловить в её DllMain() функции сигнал DLL_THREAD_ATTACH, как уже было сказано выше.

 

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

 

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

 

Аналогично, см. выше про права доступа.

 

XshStasX

Куки залочить.

Приложение может это из ядра делать.

 

XshStasX,RET Интересно, вот вы обнаружили создание или запуск удаленного потока - и что? сказать юзеру - привет! внедрен поток, прекращаю работу программы?
А если это "безобидный" поток внедрен какой-нить интерактивной программой переводчком или антивирусом, например (что можно найти у 90% юзеров)? - получится, что ваша програма станет практически неработоспособной...

 

да кстати ещё и не факт, что злоумышленник будет использовать удаленные потоки и работу с чужой приватной памятью... этим уже никого не удивишь... KAV/KIS палит CreateRemoteThread, WriteProcessMemory перехватывает Outpost... можете справиться со злоумышленником, установив эти два средства...

 

gorodon

Что-ж это уж из сказки о золотой рыбке...(хотя "вредные" потоки обычно в CreateRemoteThread передают какой нибудь параметр, но не факт).
По крайней мере в своей dll, если она инжектится, например, в несколько процессов для "защиты" от "удаленных потоков", родные потоки приложения можно оградить засплайсив NtCreateThread, соответственно, передавая сигнал в DllMain что этот поток трогать не нужно

 

Хочу просто уточнить:

Значит используя правильно настроенный DACL можно оградить себя от:
- Чтения моей памяти другими процессами (при этом не изменяя настройки клиентской машины)?
- А если мой процесс будет запущен из под user mode а злоумышленник будет запущен из под admin'a?

Зная на перед ответы на эти вопросы - грош цена, таким защитам аля DACL (и не забивайте людям голову мнимой защитой)!

Вот если бы по настроящему защититься от Write\ReadProccessMemory в юзер мод - тогда никакой CreateRemoteThread не страшен
На данный момент мне такого метода не известно, но может быть у кого нить есть хотя бы идеи, как бы это могло выглядеть (ессно без драйвера - user mode да и только) ???

 

в чтении нет ничего страшного, практически никто из защитников этого не делает...

то есть вы хотите получить все, ниимея ничего...

это все прошлый век...

грузи свою dll во все чужые процессы, перехватывай функции...

 

Резервите всю свободную память без прав на Write\Read, и некто к вам не заинжектится - некуда.

 

Ring0 - Против лома нет приёма