Dll hijacking что это
Подмена DLL (DLL hijacking)
Всем привет. Прямо сейчас в OTUS открыт набор на апрельский запуск обновленного курса «Реверс-инжиниринг». В преддверии старта курса мы традиционно подготовили перевод интересного материала.
В операционной системе Windows приложения и службы при запуске ищут DLL, необходимые для их правильного функционирования. Если эти DLL не найдены или их загрузка реализована небезопасным способом (DLL вызываются без использования полного пути), то можно повысить привилегии, заставив приложение загрузить и выполнить вредоносный DLL-файл.
Следует отметить, что когда приложению необходимо загрузить DLL, то ее поиск осуществляется в следующем порядке:
Шаг 1 — Процессы с отсутствующими DLL
На первом этапе необходимо найти процессы, которые работают от SYSTEM и пытаются загрузить отсутствующие DLL. Это можно сделать с помощью Process Monitor от Sysinternals, применив фильтр, указанный ниже:
Фильтры Procmon для поиска процессов, загружающих отсутствующие DLL
Process Monitor определит отсутствующие DLL, которые приложение пытается загрузить, и покажет фактический путь, по которому осуществляется поиск этой DLL.
Процесс с отсутствующей DLL
В данном примере для процесса Bginfo.exe отсутствует несколько DLL-файлов, которые могут быть использованы для повышения привилегий.
Шаг 2 — Разрешения на папки
Слабые разрешения на папку
Шаг 3 — Подмена DLL
С помощью Metasploit можно сгенерировать DLL с полезной нагрузкой в виде сеанса с привилегиями службы.
Генерация вредоносной DLL
Процесс Bginfo.exe запущен под SYSTEM, поэтому после перезапуска у вредоносной DLL будут такие же привилегии, так как DLL загружается и выполняется этим процессом.
Процесс запущен под SYSTEM
Вредоносная DLL переименована и размещена
Как видно ниже, при перезапуске службы с помощью подмены DLL открывается сессия Meterpreter с привилегиями SYSTEM.
Metasploit – Эскалация привилегий через подмену DLL
PowerSploit
Процесс подмены DLL можно сделать через PowerSploit, в котором есть три модуля, которые помогут в поиске служб с отсутствующими DLL, в обнаружении папок с правами на модификацию и в генерации DLL.
Модуль Find-ProcessDLLHijack найдет все процессы в системе, которые пытаются загрузить отсутствующие DLL.
PowerSploit — Обнаружение процессов с отсутствующими DLL
Следующим шагом будет определение папок, в которых пользователь может изменять содержимое. Будут найдены папки, в которые необходимо подбросить вредоносные DLL.
Обнаружение папок с правами на изменение
Последний шаг заключается в создании зловредной DLL в одной из папок с Modify (M) — разрешениями.
Создаем DLL в папке со слабыми разрешениями
Заключение
Для возможности повышения привилегий через подмену DLL должны быть выполнены следующие условия:
Сделай сам: dll hijacking под MS Office для самых маленьких
Прошло уже три дня с тех пор, как исследователь Parvez Anwar опубликовал информацию о множественных dll hijacking уязвимостях в продуктах Microsoft Office, а какой-либо реакции не наблюдается. Ни CVE, ни сообщений на специализированных ресурсах, Windows Update не качает свежих патчей. Что ж, может, так и нужно, может быть, это не уявимость, а особенность продукта?
Между тем, эксплуатация этой особенности проста и доступна даже ребенку. И, раз уж производитель пока эту «фичу» не удалил, почему бы не написать о ней небольшую статью.
Речь пойдет о Windows 7. Работает ли это на других версиях — мне на текущий момент неизвестно, нужно проверять. Принцип действия описываемого явления (как и многих других, впрочем) основан на старой доброй технологии COM/OLE/ActiveX.
Технология COM призвана воплощать ООП и повторное использование кода, позволяя любым приложениям использовать однажды созданные кем-либо классы (или компоненты), если эти классы зарегистрированы в системе. Регистрация компонента по сути представляет собой соответствующие записи в реестре. Каждому классу при его создании назначается уникальный 16-байтовый идентификатор — CLSID, который будет однозначно определять этот компонент в любое время на любом
компьютере. Глобальные идентификаторы всех зарегистрированных в системе классов содержит ветка реестра HKEY_CLASSES_ROOT\CLSID.
А что же приложения MS Office? Кроме того, что они тоже под завязку нашпигованы технологией COM (и даже сами являются COM-объектами), они еще и позволяют создавать/читать документы, содержащие элементы ActiveX.
Фактически такой документ представляет собой файл, содержащий (помимо текста, изображений, форматирования и т.п.) идентификатор компонента и некоторую информацию о свойствах встраиваемого объекта. Давайте посмотрим, как это выглядит на практике.
Открываем MS Word. Если у вас не подключена вкладка «Developer»/«Разработчик», необходимо подключить ее в настройках: File->Options->Customize Ribbon, Файл->Параметры->Настроить ленту, Файл->Параметры Word->Показывать вкладку «Разработчик» на ленте и т.п., в зависимости от того, какая версия MS Office у вас установлена.
Переходим во вкладку «Разработчик» и выбираем кнопку с молотком и гаечным ключом «Инструменты из предыдущих версий».
Затем похожую кнопку «Другие элементы управления».
В появившемся окне выберите ActiveX компонент по своему вкусу, мне нравится Microsoft Forms 2.0 Command Button.
Если открыть реестр и поискать по имени компонента, можно обнаружить, что CLSID нашего контрола
Архив содержит несколько папок с файлами. Нам нужен word\activeX\activeX1.xml
Открываем его обычным текстовым редактором и видим примерно такое содержимое.
Как видно, CLSID элемента управления присутствует и легко может быть заменен.
Теперь нужно сказать пару слов о том, на что, собственно, его можно заменить, а также о том, что такое dll hijacking, и почему это все работает.
Заменить CLSID можно на CLSID любого другого элемента управления, и не только элемента управления, но и любого ActiveX, и даже не только ActiveX, но и любого COM-класса, зарегистрированного в системе (можно и на любой случайный GUID, но это ни к каким интересным последствиям не приведет).
Все дело в том, что, прочитав идентификатор из документа, MS Word передаст его системе, система прежде всего попытается подгрузить библиотеку в память процесса и вызвать из нее первые функции (DllMain, DllGetClassObject, IClassFactory::CreateInstance и т.д.). И только после этого приложение начнет выяснять, что это за библиотека, что за компонент, можно ли добавлять его в документ, и нужно это ему вообще. Запросто может оказаться, что компонент не подходит по каким-то критериям, но это выясняется уже после того, как его исполняемый код оказался в виртуальной памяти процесса и получил управление. Он не будет выгружен даже после того, как MS Word точно установил, что ему этот класс не нужен! Такое поведение приводит к целому ряду любопытных явлений, в том числе — к описываемому в данной заметке.
Теперь о dll hijacking. «Угон динамической библиотеки» — обычное, изначальное и даже в чем-то логичное поведение приложения Windows, когда оно ищет необходимую ему библиотеку в той директории, которая является для него текущей, и только затем — в определяемых настройками ОС местах. Все бы было ничего, если бы злоумышленники довольно скоро (и довольно давно) не догадались, что можно положить рядом с документом или ярлыком собственную библиотеку с таким же названием, как и у
библиотеки, которую ожидает найти приложение.
Вообще-то этой технике уже много лет, Microsoft борется с ней давно, упорно, и, как можно видеть, до сих пор не вполне результативно.
На этот раз исследователи обнаружили затерянные в недрах операционной системы Windows 7 несколько dll, которые подгружают другие dll, и ищут их — до сих пор! — в текущей директории процесса. Эти Microsoft’ом забытые оснастки для консоли управления, присадки для Oracle’а и что-то еще столь же известное и часто используемое — оказались еще и COM-классами. Которые, как вы уже догадались, мы можем встроить в обычный документ MS Office.
Вернемся к нашему MS Word и поменяем CLSID в распакованном документе на любой удобный из отчета
Parvez Anwar. Например, на первый — <394C052E-B830-11D0-9A86-00C04FD8DBF7>.
Создание прокси-dll для проверок эксплуатации dll hijack
Когда я исследую безопасность ПО, то одним из пунктов проверки является работа с динамическими библиотеками. Атаки типа DLL hijack («подмена dll» или «перехват dll») встречаются очень редко. Скорее всего, это связано с тем, что и разработчики Windows добавляют механизмы безопасности для предотвращения атак, и разработчики софта аккуратнее относятся к безопасности. Но тем интереснее ситуации, когда целевое ПО уязвимо.
Если описать атаку коротко, то DLL hijack — это создание ситуации, в которой некоторый исполняемый файл пытается загрузить dll, но атакующий вмешивается в этот процесс, и вместо ожидаемой библиотеки происходит работа со специально подготовленной dll с полезной нагрузкой от атакующего. В результате код из dll будет исполнен с правами запускаемого приложения, поэтому в качестве цели обычно выбираются приложения с более высокими правами.
Чтобы загрузка библиотеки прошла корректно, необходимо выполнить ряд условий: битность исполняемого файла и библиотеки должна совпадать и, если библиотека загружается при старте приложения, то dll должна экспортировать все те функции, которые это приложение ожидает импортировать. Часто одного импорта мало — очень желательно, чтобы приложение продолжило свою работу после загрузки dll. Для этого необходимо, чтобы у подготовленной библиотеки функции работали так же, как и у оригинальной. Реализовать это проще всего, просто передавая вызовы функций из одной библиотеки в другую. Вот именно такие dll называют прокси-dll.
Под катом будет несколько вариантов создания таких библиотек — как в виде кода, так и утилитами.
Небольшой теоретический обзор
Загрузка библиотек чаще происходит с помощью функции LoadLibrary, в которую передается имя библиотеки. Если вместо имени передать полный путь, то приложение попытается загрузить именно указанную библиотеку. Например, вызов LoadLibrary(“C:\Windows\system32\version.dll”) приведет к загрузке именно указанной dll. Или, если библиотека не будет существовать, то не будет загружена.
Совсем другое дело, если написать LoadLibrary(“version.dll”). В обычной ситуации результат будет ровно такой же, как в предыдущем случае — загрузится C:\Windows\system32\version.dll, но не все так просто.
Сначала будет произведен поиск библиотеки, который пойдет в следующем порядке:
При запуске exe-файла ОС загружает все библиотеки из секции импорта файла. В общем смысле можно считать, что ОС принуждает файл к вызову LoadLibrary, передавая все те имена библиотек, которые написаны в секции импорта. Поскольку в 99,9% случаев там именно имена, а не пути, то при старте приложения все загружаемые библиотеки будут искаться в системе.
Из списка мест поиска dll реально нам важны два пункта — 1 и 6. Если мы подложим version.dll в ту же папку, откуда запускается файл, то вместо системного будет загружен именно подложенный. Такая ситуация практически не встречается, поскольку, если есть возможность подложить библиотеку, то, скорее всего, есть возможность и заменить сам исполняемый файл. Но все же такие ситуации возможны. Например, если исполняемый файл находится в доступной для записи папке и является сервисом с автостартом, то его нельзя изменить пока сам сервис работает. Или запускаемый файл перед стартом проверяется извне по контрольной сумме, то заменять файл все равно не вариант. А вот положить библиотеку рядом — будет вполне реально.
Возможно, нельзя создавать файлы рядом с исполняемы файлом, но можно создавать папки. В такой ситуации может сработать механизм WinSxS redirect (aka “DotLocal”).
Но и это скорее исключение, нежели правило. А вот ситуации, когда поиск dll доходит до 6 номера в списке — вполне реальны. Если приложение попытается загрузить dll, которой нет в системе или рядом с файлом, то все поиски будут доходить до 6 пункта, в котором, потенциально, могут оказаться доступные для записи папки.
Например, типовая установка Python чаще всего происходит в папку C:\Python (или близкую). Сам установщик питона предлагает добавить свои папки в системную переменную PATH. В итоге имеем хороший плацдарм для начала атаки — папка доступна для записи всем пользователям и любая попытка загрузить несуществующую библиотеку дойдет до поиска в путях из PATH.
Теперь, когда теория пройдена, рассмотрим создание полезной нагрузки — самих прокси-библиотек.
Первый вариант. Честная прокси-библиотека
Начнем с относительно простого — сделаем честную прокси-библиотеку. Честность в данном случае подразумевает, что все функции в dll будут прописаны явно, и для каждой функции будет написан вызов функции с тем же именем из оригинальной библиотеки. Работа с такой библиотекой будет полностью прозрачна для вызываемого кода: если тот вызывает некоторую функцию, то он получит корректный ответ, результат и все, что там побочно должно произойти.
Вот ссылка на готовый пример (github) библиотеки version.dll.
Основные моменты кода:
Второй вариант. Упрощаем написание кода
Когда имеешь дело с библиотекой типа version.dll, где таблица импорта небольшая, всего 17 функций, и прототипы простые, то честная прокси-библиотека — хороший выбор.
А вот если прокси для библиотеки, например, bcrypt, то все сложнее. Вот ее таблица импорта:
57 функций! Причем вот пара примеров прототипов:
Скажем так, нет ничего невозможного, но делать честную прокси для такой библиотеки не очень приятно.
Упростить код можно, если немного схитрить с функциями. Объявим все функции в библиотеке как __declspec(naked), а в теле — код на ассемблере, который просто сделает jmp на функцию из оригинальной библиотеки. Это позволит нам не использовать длинные прототипы, а поставить везде простые объявления без параметров вида:
Когда приложение вызовет нашу функцию, то прокси-библиотека не будет проводить никаких манипуляций с регистром и стеком, позволяя оригинальной функции делать всю работу как надо.
Пример (github) библиотеки version.dll с таким подходом.
Третий вариант. Выкидываем тело вообще
Использование naked наводит на мысли еще об одном варианте. Можно создать таблицу импорта, которая для всех функций будет ссылаться на одну реальную строчку кода:
Такая библиотека будет загружена приложением, но не будет работать. При вызове любой из функций будет, скорее всего, порван стек или случится еще какая-то гадость. Но это не всегда и плохо — если, например, цель dll-инъекции просто запустить код с нужными правами, то достаточно исполнить полезную нагрузку из DllMain прокси-библиотеки и тут же тихо завершить работу приложения. В таком случае до реального вызова функций дело не дойдет и ошибок-падений не появится.
Пример на гитхабе, опять для version.dll.
Основные моменты кода:
Четвертый вариант. Возьмем готовые утилиты
Писать dll это хорошо, но не всегда удобно и не очень быстро, поэтому стоит рассмотреть автоматизированные варианты.
Можно пойти по пути старых вирусов — взять библиотеку, прокси которой хотим сделать, создать в ней исполняемую секцию кода, записать туда полезную нагрузку и поменять точку входа на эту секцию. Не самый простой способ, потому что можно что-то сломать ненароком, придется писать на ассеблере, вспоминать устройство PE-файла. Это не наш путь.
Для эксплуатации dll hijack мы добавим еще один dll hijack.
Сделать это относительно просто. Скопируем библиотеку, прокси которой хотим сделать, и добавим в таблицу импорта этой копии какую-то dll с произвольной функцией. Теперь загрузка пойдет по цепочке — при старте исполняемого файла будет загружена прокси-dll, которая сама загрузит указанную библиотеку.
«Хей, ты же заменил загрузку одной библиотеки другой. В чем смысл? Все равно надо будет кодить dll!». Все правильно, но смысл все же есть. Теперь к библиотеке с полезной нагрузкой будет меньше требований. Имя можно задать любое, главное экспортировать всего одну функцию, у которой может быть любой прототип. Главное имя библиотеки и функции вписать в таблицу импорта.
А библиотека с полезной нагрузкой может быть одна на все случаи жизни.
Модифицировать таблицу импорта можно многими редакторами PE, например CFF explorer или pe-bear. Для себя я написал небольшую утилиту на C#, которая правит таблицу без лишних телодвижений. Исходники на гитхабе, бинарь в разделе Release.
Заключение
В статье я постарался раскрыть основные способы создания прокси-dll, которыми пользовался сам. Осталось только рассказать, как защищаться.
Универсальных рекомендаций не так много:
UPD: По советам комментаторов напоминаю о том, что выбирать библиотеку нужно аккуратно и внимательно. Если бибилиотека входит в список KnownDlls или имя похоже на MinWin (ApiSetSchema, api-ms-win-core-console-l1-1-0.dll — вот это вот все), то скорее всего перехватить ее не удастся из-за особенносей обработки таких dll в ОС.
DLL Hijacking для Windows
DLL Hijacking — это популярный метод осуществления вредоносных полезных нагрузок. В этой статье перечислены около 300 исполняемых файлов, уязвимых для данной атаки в Windows 10, а также показано, как с помощью нескольких строк VBScript могут быть выполнены некоторые из вариантов DLL Hijacking с повышенными привилегиями, минуя UAC.
DLL Hijacking
Прежде всего, нужно разобраться с определением этого понятия. DLL Hijacking — это, в самом широком смысле, обман легитимного (доверенного) приложения для загрузки произвольной библиотеки DLL. Такие термины, как DLL Search Order Hijacking, DLL Load Order Hijacking, DLL Spoofing, DLL Injection и DLL Side-Loading часто ошибочно используются для того, чтобы дать определение этому понятию. В лучшем случае эти термины описывают какие-то конкретные случаи DLL Hijacking, но часто применяются взаимозаменяемо и, следовательно, не совсем верно. Как зонтичный термин, DLL Hijacking является более точным определением, так как он включает в себя захват DLL из легитимной DLL.
Стоит отметить, что злоумышленники используют эту атаку по-разному и по многим причинам. Выбор часто склоняется к ней, так как DLL Hijacking охватывает выполнение (выполнение вредоносного кода через доверенный исполняемый файл, что может с меньшей вероятностью вызвать сигналы тревоги системы, а в некоторых случаях даже обойти белый список приложения, такого как AppLocker), получение персистентности (если целевое приложение предварительно установлено и работает постоянно, то и вредоносный код тоже будет функционировать соответственно) и эскалацию привилегий (если целевое приложение работает с повышенными привилегиями, то и вредоносный код будет функционировать соответственно).
Существует множество подходов, успех которых зависит от того, какие настройки имеет приложение относительно загрузки необходимых библиотек DLL. Среди возможных вариантов выделяют:
Поиск уязвимых исполняемых файлов
Самой большой проблемой является поиск уязвимого исполняемого файла, который можно использовать с разрешениями пользователя по умолчанию. При таргетинге на предустановленные системные исполняемые файлы в Windows атака обычно исключает первый подход, в то время как любые папки, соответствующие 2 и 3 способу, должны быть доступны для записи пользователем, как и файлы и папки в вариантах 4 и 5. Однако, это все мимо.
Следует уделить внимание шестому, самому слабому методу, о котором и пойдет речь в данной статье, хотя обычно он не подходит для получения персистенции или эскалации привилегий. Нужно работать с OceanLotus / APT32, которые в конце 2019 года уже использовались для применения законного rekeywiz.exe вместе с вредоносным duser.dll. В этом случае программа внедряет законное программное обеспечение и сбросывает его на диск, применив подход «bring your own LOLbin» (другой способ достижения такого же результата заключается в копировании легитимного исполняемого файла из папки \system32\, предполагая, что исполняемый файл еще не был пропатчен).
Для того чтобы предотвратить осуществление других атак, стоит определить исполняемые файлы, которые уязвимы для такого рода DLL hijacking. Это даст «красным командирам» новые средства для проведения «казни», но, что более важно, позволит охотникам за потенциальными угрозами и защитникам принять соответствующие меры для обнаружения и предотвращения будущих нападений.
Подход
Для того чтобы не запутаться, надо ограничиться исполняемыми файлами, присутствующими по умолчанию в c:\windows\system32\. В тестируемом экземпляре Windows 10 v1909 это составляло в общей сложности 616 исполняемых файлов или 613, если рассматривать только подписанные приложения.
Для отслеживания того, какие библиотеки DLL загружаются с каждым процессом, нужно применить хорошо известный инструмент Procmon. Таким образом, используемый подход заключается в следующем: доверенный исполняемый файл копируется в место, доступное для записи пользователем; он запускается и применяется Procmon для идентификации библиотек DLL, которые разыскиваются в месте, доступном для записи пользователем.
На картинке видно, как это работает.
Такой подход позволяет идентифицировать все библиотеки DLL, запрашиваемые каждым приложением, которые станут потенциальными кандидатами для проведения атаки DLL Hijacking. Самый надежный способ узнать, какие библиотеки DLL правильно загружены, — это скомпилировать собственную версию библиотеки DLL и сделать ее запись в уникальный файл после успешной загрузки. Если затем повторить описанный выше подход для всех целевых исполняемых файлов и библиотек DLL, это приведет к созданию коллекции файлов, которая даст пользователю понимание того, какие библиотеки DLL уязвимыми для DLL Hijacking.
Компиляция пользовательских версий существующих библиотек DLL является более сложной задачей, чем может показаться, поскольку многие исполняемые файлы не будут загружать такие библиотеки DLL, если не выполняются нужные процессы или отсутствуют точки входа. Такие инструменты, как DLL Export Viewer, можно использовать для перечисления всех внешних имен функций и ординалов законных библиотек DLL. Это гарантирует, что скомпилированная библиотека DLL будет в том же формате, что увеличивает шансы на ее успешную загрузку.
Пример кода для версии dxgi.dll, которая появилась в записи Procmon winsat.exe.
Таким образом, принятый подход заключается в следующем:
Полный код с более подробным техническим объяснением можно найти на GitHub.
Подтвержденные файлы для проведения атаки DLL Hijacking
В таблице перечислены все исполняемые файлы в c:\windows\system32 в Windows 10 v1909, которые уязвимы для «относительного пути DLL Hijack». Рядом с каждым исполняемым файлом находится одна или несколько библиотек DLL, которые могут быть захвачены вместе с вызываемыми процедурами этой библиотеки. Как объяснялось в предыдущем разделе, это не просто теория, все проверено практическим путем. Список состоит из 287 исполняемых файлов и 263 уникальных DLL-файлов.
СVS-версия таблицы может быть найдена на GitHub.
Корреляция с обходом UAC
Найдя все эти исполняемые файлы, пользователь сможет выполнять код через доверенные программы. Однако также он имеет возможность получить привилегированные права, если использовать их в сочетании с методами обхода UAC.
Контроль учетных записей пользователей (UAC) появился в Windows Vista в качестве функции, связанной с безопасностью системы; он запрашивал у пользователей подтверждение через приглашение, прежде чем процесс, работающий с обычными привилегиями, будет повышен до более высокого уровня. После того как пользователи пожаловались на миллион подсказок UAC при выполнении произвольных задач, Microsoft ввела автоматическое повышение уровня привилегий в Windows 7, которое автоматически повышает уровень некоторых процессов, если они находятся в доверенных каталогах (например c:\windows\system32 ).
Имея это в виду, пользователь может попробовать запустить произвольный код с повышенными привилегиями, используя исполняемый файл, помеченный для автоматического повышения, который также уязвим для захвата DLL. Существует около 35 таких исполняемых файлов. Проблема, от которой нужно избавиться, содержится в доверенном каталоге: и исполняемый файл автоматического повышения уровня, и пользовательская библиотека DLL должны быть расположены в одном доверенном каталоге, но ни один из них не может быть записан пользователем.
Существует несколько превосходных исследований об обходе UAC: к примеру, вот этот. Желательно прочитать статью полностью, но все сводится к тому, что пользователи могут создавать c:\windows \system32\ (надо обратить внимание на пространство после первой папки) и автоматически повысить статус исполняемых файлов, помещенных в эту папку.
Спорно, является ли это настоящей уязвимостью для безопасности. Microsoft утверждает, что это не совсем так, но, по крайней мере, данный недостаток присущ большинству компьютеров, работающих на Windows.
В любом случае, это дает пользователю отличную возможность для захвата DLL. Стоит обратить свое внимание, что папки с конечными пробелами не могут быть созданы традиционными средствами в Windows. Пользователь способен скомпилировать некоторые строки C, чтобы создать их, как это делает оригинальный исследователь, но оказывается, что VBScript действительно может справиться сам. Данное доказательство всей концепции указывает на то, что с помощью всего нескольких строк кода пользователь добьется успеха без проблем:
На скриншоте ниже показано, как может выглядеть выполнение скрипта.
Пример, на котором видно, что файл обладает повышенными привилегиями после того, как вредоносный DXGI.dll был загружен с помощью легитимного winsat.exe из нужного доверенного каталога, не получая никаких подсказок от UAC.
В приведенной таблице все комбинации исполняемых файлов и DLL, для которых автоматическое повышение уровня было успешным, помечены в первом столбце. Среди более чем 160 возможных комбинаций пользователь способен выбрать подходящую ему.
Профилактика и выявление
Простой способ предотвратить захват DLL-файлов заключается в том, чтобы приложения всегда использовали абсолютные пути вместо относительных. Хотя некоторые приложения (особенно портативные) не всегда смогут это сделать; программы, расположенные в \system32\ и полагающиеся на библиотеки DLL в той же папке, не имеют никаких оправданий для того, чтобы поступать иначе. Лучшим вариантом является проверка всех библиотек DLL перед их загрузкой (например, путем проверки их сигнатур), что в значительной степени предотвратит появление проблем.
Тем не менее, злоумышленники все еще смогут использовать более старые версии легитимных приложений. Поэтому, даже если каждое приложение начнет проверять свои библиотеки DLL перед загрузкой, вероятность возникновения проблем все еще существует.
Нужно сосредоточиться на обнаружении нападения. Пользователь может постоянно следить за созданием или загрузкой любой из упомянутых ранее библиотек DLL из неожиданных путей, особенно во временных местоположениях, таких как %appdata%. В конце концов, имя (законного) приложения, загружающего библиотеки DLL, может быть изменено, но имена файлов библиотек DLL всегда фиксированы. Доказательство этого утверждения можно найти здесь: успешно обнаруживается захват DLL, хотя, как видно, есть склонность к ложным срабатываниям. Пользователь способен использовать более общий подход, применяя поиск подписанных Microsoft двоичных файлов в неожиданных местах, загрузки библиотек DLL из неожиданных мест.
Наконец, продемонстрированный метод обхода UAC может быть легко обнаружен путем поиска любой активности в папке / windows / или в любых папках, заканчивающихся пространством. Как описано выше, папки Windows с конечными пробелами не могут быть созданы обычным способом и поэтому их создание всегда вызывает подозрение. Установка постоянных уведомление на UAC предотвратит этот и другие подобные методы обхода.
Важно! Информация исключительно в учебных целях. Пожалуйста, соблюдайте законодательство и не применяйте данную информацию в незаконных целях.