Итак, на днях я увидел это:
https://web.archive.org/web/20090904193405/https://www.edgeofnowhere.cc/viewtopic.php?p=2483118
и он использует три различных метода внедрения DLL. Как я могу предотвратить это от процесса? Или, как минимум, как предотвратить первый?
Я подумал, что, возможно, драйвер Ring 0 может быть единственным способом остановить все три, но я хотел бы узнать, что думает сообщество.
Лучшим техническим решением было бы сделать что-то, из-за чего код загрузчика не сможет работать должным образом после инициализации вашего процесса. Один из способов сделать это — взять блокировку загрузчика NT, которая эффективно предотвратит любые действия загрузчика. Другие варианты включают исправление кода загрузчика непосредственно в памяти, чтобы вызовы LoadLibrary не выполнялись для злоумышленника (например, вставка точки останова int3 и самостоятельная отладка для обработки ожидаемых случаев).
Но, говоря как хакер (фактически тот, кто является администратором сайта, на который вы ссылаетесь), вы никогда не помешаете людям получить код в ваш процесс, так или иначе. LoadLibrary просто оказался удобным ярлыком, но есть множество различных способов загрузки кода вручную, которые вы никогда не сможете полностью остановить, за исключением какого-то чрезвычайно сложного кода Ring0. И даже если вы отправитесь на ринг0, хакеры будут рядом с вами.
Кроме того, существует множество законных применений внедрения DLL. Тематические программы, инструменты специальных возможностей и различные программы, расширяющие функциональные возможности ОС, потенциально могут использовать внедрение DLL для расширения функциональности любой программы.
Как защититься от этих 3 методов:
Вы можете предотвратить первый метод (CreateRemoteThread, который вызывает LoadLibrary), перехватив LoadLibrary. В своем хуке вы проверяете список имен DLL, которые, как вы знаете, являются частью процесса и которые могут быть загружены, или вы можете сверяться со списком известных DLL, которые вы не хотите загружать.
Когда вы найдете DLL, вы не хотите загружать SetLastError (ERROR_ACCESS_DENIED), а затем вернуть NULL. Я установил последнюю ошибку, чтобы люди, которые пишут код в поисках кода ошибки, получили его. Кажется, это работает, возможно, другой код может быть более подходящим.
Это остановит загрузку DLL.
Я думаю, что та же техника для блокировки CreateRemoteThread будет работать и для SetWindowsHookEx, но только в том случае, если вы сможете установить свой хук до того, как метод SetWindowsHookEx начнет загружать свой код (что обычно происходит, когда в приложении создается первое окно — так рано в его жизни). ).
Хорошая техника. Не видел такого раньше. Вы можете защититься от этого, но вам придется перехватить точку входа LoadLibrary (а не таблицу IAT), поскольку Code Cave напрямую вызывает LoadLibrary.
Как прокомментировал автор статьи, есть много способов, которыми вас могут атаковать, и вам, вероятно, будет трудно победить их все. Но часто вы хотите защититься только от определенных загрузок DLL (например, от конкретной сторонней DLL, которая несовместима с вашим программным обеспечением, потому что сторонняя DLL не была написана должным образом, чтобы учесть тот факт, что может присутствовать другой хук, поэтому вы блокируете это от загрузки).
Наилучшим способом было бы гарантировать, что ни один ненадежный процесс не получит доступ администратора или не запустится под той же учетной записью пользователя, что и ваше приложение. Без этого доступа внедрение кода в ваше приложение невозможно; и как только такой процесс получает этот доступ, он может причинять все виды вреда без необходимости внедрять себя в другой процесс - внедрение просто облегчает его сокрытие.
Поскольку этот плакат намекает на то, что он инвестирует в игру против взлома, позвольте мне пролить свет на то, что я думаю. Как бывший мошенник.
Просто указка об игре против взлома.
Лучше всего позволить серверу выполнять основную логику игры. например В шутере от первого лица отслеживайте движения, которые клиенты отправляют на сервер. Не позволяйте им перемещаться наугад. Пусть сервер сообщает клиентам, где находится каждый игрок, исходя из собственной логики. Никогда не пересылайте команды. Они могут быть фиктивными.
Кого волнует, взламывает ли хакер собственный клиент? просто откажитесь от него на других и все хорошо. Для картстаркрафтеров решение простое. Не выдавайте состояние игры для областей, которые должны быть неизвестны. Это также экономит пропускную способность.
Я был большим читером в Delta Force (это старая игра). Основной трюк, который я использовал, заключался в том, чтобы деформировать любое место в игре, напрямую изменяя память процесса. DLL не требуется!
Вы ищете решение Ring3? Если это так, вы хотите встроить в систему дополнительные функции, которые в настоящее время (по крайней мере, насколько мне известно) не предоставляются в готовом виде, поэтому для этого потребуется некоторая работа. Кроме того, это возможно с помощью драйвера, на самом деле большая часть вашего антивирусного программного обеспечения регулярно выполняет этот тип деятельности.
Что касается остановки вышеперечисленных методов из пользовательского режима, это становится немного сложнее, поскольку вы не можете просто зарегистрировать себя в качестве обратного вызова для создания процесса или загрузки DLL. Однако вы можете, если предполагаете, что ваш процесс запустился раньше, чем их, перехватить CreateRemoteThread и подобные функции глобально и выполнить этот тип проверки самостоятельно.
Таким образом, вы, по сути, захотите проверить, где CreateRemoteThread хочет создать поток, и вернуть ошибку, если вас это не устраивает.
Это сведет на нет первые два метода. Для третьего метода, если у вас есть действительные хэши оригинальной программы на диске, вы всегда можете проверить хэш перед его загрузкой. Если у вас нет хэшей, вы можете, по крайней мере, просто проверить некоторые из простых мест, где кто-то добавит код такого типа, и поискать библиотеки DLL, которые вы не ожидаете там найти (например, IAT или строки запуска).
Это не надежно, но, похоже, дает запрошенную вами функциональность.
Просто краткие мысли для обсуждения :)
Использование пещеры кода для внедрения проверки CRC в ваш собственный код, возможно, замедлит использование другими пещерами кода.
Опрос списка модулей процесса на наличие загружаемых неизвестных dll может помочь замедлить людей, просто внедряющих какие-либо старые вещи с помощью потоков прикрепления и перехватчиков сообщений.
Почему вы хотите предотвратить это? Это реальная «деловая» потребность, или вы просто заинтересованы в «хаке», чтобы противостоять «хаку»?
Если это разрешено правами пользователя, то это сделано специально — ОС предоставляет возможность всем пользователям, которых вы, администратор системы, назначили учетным записям, под которыми они работают.
Рэймонд Чен скоро свяжется здесь...
Я не очень хорошо знаком с Windows API, но могу дать вам несколько более общих указаний:
Посмотрите, можете ли вы использовать предотвращение выполнения данных Windows (DEP). Вероятно, это не сработает для всех (читай: большинства) ситуаций, потому что процесс, описанный в вашей ссылке, является допустимым процессом с точки зрения ОС. Глубокая защита, однако
Убедитесь, что ваши методы процесса утверждают разрешения безопасности во всем приложении.
Статически выделяйте пространство памяти, чтобы любые новые потоки, порожденные в нем, либо терпели неудачу, либо перезаписывали существующее пространство памяти; вам, вероятно, понадобится изрядный кусок логики, чтобы обнаружить и исправить это.
Включите свой код в драйвер устройства или какой-либо другой низкоуровневый процесс, который вы можете охватить защитой файлов Windows.
Только что увидел ответ Ктулона, и я боюсь, что он, вероятно, прав: любой, кто хочет выполнить инъекцию кода в вашем приложении, найдет способ сделать это. Приведенные выше шаги могут просто немного усложнить задачу.
Надеюсь это поможет
