Как предотвратить внедрение DLL
Итак, на днях я увидел это:
http://www.edgeofnowhere.cc/viewtopic.php?p=2483118
и это идет по трем различным методам внедрения DLL. Как бы я предотвратить это от процесса? Или как минимум, как я могу предотвратить первый?
Я думал, что, возможно, драйвер Ring 0 может быть единственным способом остановить все три, но я хотел бы посмотреть, что думает сообщество.
9 ответов
Наилучшим техническим решением было бы сделать что-то, из-за чего код загрузчика не сможет работать должным образом после инициализации вашего процесса. Одним из способов сделать это является блокировка загрузчика NT, которая эффективно предотвращает любые действия загрузчика. Другие варианты включают в себя исправление кода загрузчика непосредственно в памяти для сбоя вызовов LoadLibrary для злоумышленника (например, вставка точки останова int3 и отладка для обработки ожидаемых случаев).
Но, выступая как хакер (тот, кто на самом деле управляет сайтом, на который вы ссылались), вы никогда не будете мешать людям вводить код в ваш процесс, так или иначе. LoadLibrary - просто удобный ярлык, но есть множество различных способов загрузки кода вручную, которые вы никогда не сможете полностью остановить, если не считать какого-то чрезвычайно сложного кода ring0. И даже если вы пойдете на ring0, хакеры будут рядом с вами.
Кроме того, существует множество законных способов использования DLL-инъекций. Тематические программы, инструменты специальных возможностей и различные программы, расширяющие функциональные возможности ОС, потенциально могут использовать DLL-инъекцию для придания дополнительной функциональности любой программе.
Как защититься от этих 3 методов:
CreateRemoteThread
Вы можете предотвратить первый метод (CreateRemoteThread, который вызывает LoadLibrary), подключив LoadLibrary. В своей ловушке вы проверяете список имен DLL, которые, как вы знаете, являются частью процесса и которые могут быть загружены, или вы можете сверять список известных библиотек DLL, которые вы не хотите загружать.
Когда вы найдете DLL, которую не хотите загружать SetLastError(ERROR_ACCESS_DENIED), затем возвращайте NULL. Я установил последнюю ошибку, чтобы люди, которые пишут код в поисках кода ошибки, получили его. Кажется, это работает, возможно, другой код может быть более подходящим.
Это остановит загрузку DLL.
SetWindowsHookEx
Я думаю, что та же самая техника для блокировки CreateRemoteThread будет работать для SetWindowsHookEx, но только если вы сможете установить свой хук до того, как метод SetWindowsHookEx начнет загружать свой код (как правило, когда первое окно создается в приложении - так рано в его жизненном цикле).).
Код пещера
Хорошая техника. Не видел этого раньше. Вы можете защититься от этого, но вам придется подключить точку входа LoadLibrary (не таблицу IAT), так как Code Cave напрямую вызывает LoadLibrary.
Как прокомментировал автор статьи, существует множество способов нападения, и вам, вероятно, будет трудно победить их всех. Но часто вам нужно защищаться только от определенных загрузок DLL (например, от конкретной сторонней DLL, которая несовместима с вашим программным обеспечением, потому что сторонняя DLL не была написана должным образом, чтобы учесть тот факт, что другой хук также может присутствовать, поэтому вы блокируете это с загрузки).
Лучшим способом было бы убедиться, что ни один ненадежный процесс не получит доступ администратора или не будет работать с той же учетной записью пользователя, что и ваше приложение. Без этого доступа внедрение кода в ваше приложение невозможно; и как только такой процесс получает такой доступ, он может вызывать все виды вреда без необходимости встраивать себя в другой процесс - это просто облегчает скрытие.
Поскольку этот плакат намекает на то, что он вкладывает средства в анти-хакерство, позвольте мне пролить свет на то, что я думаю. Как бывший мошенник.
Просто указатель на игру против взлома.
Лучший способ - позволить серверу запустить ядро игровой логики. Например, в шутере от первого лица следите за движениями, которые клиенты отправляют на сервер. Не позволяйте им передвигаться наугад. Пусть сервер сообщает клиентам, где каждый игрок основан на своей собственной логике. Никогда не просто отправляйте команды. Они могут быть поддельными.
Кому какое дело, если хакер взломает своего клиента? просто откажись от остальных и все хорошо. Для картографов Starcraft решение простое. Не выдавайте gamestate для областей, которые должны быть неизвестны. Это также экономит пропускную способность.
Я был большим обманщиком в Delta Force (это старая игра). Основной трюк, который я использовал, заключался в том, чтобы деформировать любое место в игре, напрямую изменяя память процесса. DLL не требуется!
Вы ищете решение Ring3 тогда? Если это так, вы хотите встроить в систему дополнительные функциональные возможности, которые в настоящее время (по крайней мере, насколько мне известно) не предоставляются "из коробки", поэтому потребуется немного поработать. Кроме того, это возможно с помощью драйвера, фактически большая часть вашего программного обеспечения AV выполняет этот тип деятельности регулярно.
Что касается остановки вышеупомянутых методов в пользовательском режиме, это становится немного сложнее, поскольку вы не можете просто зарегистрировать себя как обратный вызов для создания процесса или загрузки DLL. Однако вы можете, если вы предполагаете, что ваш процесс запущен раньше, чем они, подключите CreateRemoteThread и подобные функции глобально и выполните этот тип проверки самостоятельно.
Таким образом, в действительности вы захотите проверить, где CreateRemoteThread хочет создать поток и вернуть ошибку, если вас это не устраивает.
Это сведет на нет первые два метода. Для третьего метода, если у вас есть действительные хеши исходной программы на диске, вы всегда можете проверить хеш перед загрузкой. Если у вас нет хэшей, вы можете, по крайней мере, просто проверить некоторые простые места, в которых кто-то добавил бы этот тип кода, и найти библиотеки DLL, которых вы не ожидаете найти (например, IAT или запустить строки).
Это не защищает от ошибок, но, похоже, дает требуемую функциональность.
Просто краткие мысли для обсуждения:)
Использование пещеры кода для внедрения проверки CRC в ваш собственный код, возможно, замедлит других от использования других пещер кода.
Опрос списка модулей процесса для загрузки неизвестных библиотек DLL может помочь замедлить людей, просто внедряющих любую старую вещь с присоединяемым потоком и перехватом сообщений.
Почему вы хотите предотвратить это? Это фактическая потребность в бизнесе, или вы просто заинтересованы в "взломе", чтобы противостоять "взлому"
Если права пользователей позволяют это, то это специально - ОС предоставляет возможность всем пользователям, которых вы, администратор системы, назначили учетным записям, под которыми они работают.
Раймонд Чен скоро будет здесь связываться...
Я не очень хорошо знаком с Windows API, но могу дать вам несколько обобщенных указателей:
Посмотрите, можете ли вы использовать Windows Data Execution Prevention (DPE). Это, вероятно, не будет работать для всех (читай: большинства) ситуаций, потому что процесс, описанный в вашей ссылке, является допустимым процессом с точки зрения ОС. Хотя глубоко в обороне
Убедитесь, что ваши методы процесса утверждают разрешения безопасности во всем приложении
Статически распределите пространство памяти так, чтобы любые новые потоки, созданные в нем, либо перестали работать, либо перезаписывали существующее пространство памяти; Вам, вероятно, понадобится здоровенный кусок логики, чтобы обнаружить и исправить это.
Включите ваш код в драйвер устройства или в какой-либо другой процесс низкоуровневого типа, который вы можете охватить зонтиком Windows File Protection.
Только что увидел ответ Ктулона (хорошее имя, кстати!), И я боюсь, что он, вероятно, прав: любой, кто хочет выполнить внедрение кода в ваше приложение, найдет способ сделать это. Шаги, приведенные выше, могут просто сделать это немного сложнее.
Надеюсь это поможет
Я опаздываю на вечеринку, но подумал, что все равно должен поделиться.
Приложение должно быть подписано надежными криптографическими алгоритмами. Существует 3 различных метода, используемых для внедрения DLL. Чтобы предотвратить внедрение DLL, выполните следующие действия:
CreateRemoteThread Вы можете предотвратить первый метод (CreateRemoteThread, который вызывает LoadLibrary), перехватив LoadLibrary. В своем хуке вы проверяете список имен DLL, которые, как вы знаете, являются частью процесса и которые могут быть загружены, или вы можете сверяться со списком известных DLL, которые вы не хотите загружать. Когда вы найдете DLL, которую не хотите загружать
SetLastError(ERROR_ACCESS_DENIED)затем вернуть NULL. Я установил последнюю ошибку, чтобы люди, которые пишут код в поисках кода ошибки, получили его. Кажется, это работает, возможно, другой код может быть более подходящим. Это остановит загрузку DLL.SetWindowsHookEx Тот же метод блокировки CreateRemoteThread будет работать и для SetWindowsHookEx, но только в том случае, если вы сможете установить хук до того, как метод SetWindowsHookEx начнет загружать свой код (что обычно происходит, когда в приложении создается первое окно — так рано в его жизни). .
Code Cave Вы можете защититься от этого, но вам придется перехватить точку входа LoadLibrary (а не таблицу IAT), поскольку Code Cave напрямую вызывает LoadLibrary. Есть много способов, которыми вас могут атаковать, и вам, вероятно, будет трудно победить их все. Но часто вы хотите защититься только от определенных загрузок DLL (например, от конкретной сторонней DLL, которая несовместима с вашим программным обеспечением, потому что сторонняя DLL не была написана должным образом с учетом того факта, что может присутствовать другой хук, поэтому вы блокируете это от загрузки). Кроме того, цифровая подпись приложения. Это обеспечит подлинность и целостность исполняемого приложения.