[Информационная безопасность, Разработка под Windows] Автоматизация обнаружения возможных путей перехвата DLL (DLL Hijacks) (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, хабровчане. Прямо сейчас открыт набор на новый поток курса «Пентест. Практика тестирования на проникновение». В преддверии старта курса делимся с вами переводом интересного материала.
Введение
В этой статье мы рассмотрим концепцию перехвата порядка поиска динамически подключаемых библиотек (DLL hijacking) и то, как она может быть использована для достижения устойчивости (persistence) в юзерленде в системах Windows. Этот метод описан в MITER ATT&CK в разделе: «Перехват порядка поиска DLL (T1038)».
Подмена DLL может быть использована злоумышленниками для множества разных целей, но в этой статье основное внимание будет уделено достижению устойчивости с помощью приложений с автозапуском. Например, поскольку Slack и Microsoft Teams запускаются при загрузке (по умолчанию), подмена DLL в одном из этих приложений позволит злоумышленнику получить устойчивый доступ к своей цели — всякий раз, когда пользователь входит в систему.
После представления концепции DLL, порядка поиска DLL, и подмены DLL, я раскрою процесс автоматизации обнаружения возможности перехвата DLL. В этой статье будет рассказано об обнаружении путей перехвата DLL в Slack, Microsoft Teams и Visual Studio Code.
Наконец, я обнаружил несколько путей перехвата DLL, которые использовались разными приложениями, исследовал основную причину и обнаружил, что приложения, использующие определенные вызовы API Windows, подвержены перехвату DLL, когда не работают из C:\Windows\System32\.
Я хочу поблагодарить своего коллегу Джозайю Массари (@Airzero24) за то, что он первым обнаружил некоторые из этих перехватов DLL, объяснил их методологию и вдохновил меня автоматизировать обнаружение.
Что такое DLL?
DLL — это библиотека, содержащая код и данные, которые могут использоваться одновременно более чем одной программой. (Сурс)
Функциональные возможности DLL могут быть использованы приложением Windows с помощью одной из функций LoadLibrary*. Приложения могут ссылаться на DLL, разработанные специально для этих приложений, или DLL Windows, уже находящиеся на диске в System32. Разработчики могут загружать DLL из System32, чтобы использовать в своих приложениях функционал, уже реализованный в Windows, без необходимости писать этот функционал с нуля.
Например, разработчик, которому необходимо выполнять HTTP-запросы, может использовать библиотеку WinHTTP (winhttp.dll) вместо реализации HTTP-запросов с использованием сырых сокетов.
Порядок поиска DLL и перехват
Поскольку DLL существуют в виде файлов на диске, вы можете задаться вопросом, как приложение узнает, откуда загружать DLL? Microsoft подробно задокументировала порядок поиска DLL здесь.
Начиная с Windows XP SP2, безопасный режим поиска DLL включен по умолчанию (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode). При включенном безопасном режиме порядок поиска DLL следующий:
- Каталог, из которого загружено приложение.
- Системный каталог. Используйте функцию GetSystemDirectory, чтобы получить путь к этому каталогу.
- 16-битный системный каталог. Функции, которая предоставляет путь к этому каталогу, нет, но в нем происходит поиск.
- Каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь к этому каталогу.
- Текущий каталог.
- Каталоги, перечисленные в переменной среды PATH. Обратите внимание, что сюда не входят пути для каждого приложения, указанные в разделе реестра App Paths. Ключ App Paths не используется при вычислении пути поиска DLL.
Система может содержать несколько версий одной и той же DLL. Приложения могут управлять выбором расположения, из которого должен загружается DLL, путем указания полного пути или использования другого механизма, такого как манифест. (Сурс)
Если приложение не указывает, откуда загружать DLL, Windows использует порядок поиска DLL по умолчанию, приведенный выше. Первая позиция в порядке поиска DLL (каталог, из которого загружается приложение) представляет интерес для злоумышленников.
Если разработчик приложения предполагает загрузку DLL из C:\Windows\System32, но явно не прописал это в приложении, вредоносная DLL, помещенная в каталог приложения, будет загружена раньше, чем легитимная DLL из System32. Загрузка вредоносной DLL называется подменой (или перехватом) DLL и используется злоумышленниками для загрузки вредоносного кода в доверенные/подписанные приложения.
Использование подмены DLL для достижения устойчивости
Подмена DLL может использоваться для достижения устойчивости, когда уязвимое приложение/служба запускается и вредоносная DLL размещается в уязвимом месте. Мой коллега, @Airzero24, обнаружил подмену DLL в Microsoft OneDrive, Microsoft Teams и Slack в виде userenv.dll.
Именно эти программы стали целью перехвата, потому что по умолчанию они настроены на запуск при загрузке Windows. Это можно увидеть ниже в диспетчере задач:
Приложения Windows, настроенные на автозапуск
Чтобы проверить подмену DLL, я создал загрузчик шеллкода DLL, который запускал Cobalt Strike Beacon. Я переименовал вредоносную DLL в userenv.dll и скопировал ее в каталог уязвимого приложения. Я запустил приложение и увидел свой новый Beacon коллбек.
Cobalt Strike Beacon через перехват DLL
Используя Process Explorer, я могу проверить, действительно ли моя вредоносная DLL была загружена уязвимым приложением.
Обозреватель процессов, показывающий загруженную вредоносную DLL
Автоматическое обнаружение возможности перехвата DLL
После подтверждения ранее известного перехвата DLL, я хотел проверить, смогу ли я найти другие возможности для подмены DLL, которые можно было бы эксплуатировать.
Код, использованный в моих проверка, можно найти здесь: https://github.com/slyd0g/DLLHijackTest
На примере Slack
Чтобы начать этот процесс, я запустил Process Monitor (ProcMon) со следующими фильтрами:
- Имя процесса — slack.exe
- Результат содержит NOT FOUND
- Путь заканчивается на .dll.
Поиск отсутствующих DLL в ProcMon.
Затем я запустил Slack и изучил ProcMon на предмет любых DLL, которые Slack искал, но не смог найти.
Возможные пути перехвата DLL, обнаруженные с помощью ProcMon
Я экспортировал эти данные из ProcMon в виде CSV файла для облегчения парсинга в PowerShell.
С моей текущей DLL загрузчика шелл-кода я не смог бы легко определить имена DLL, которые были успешно загружены Slack. Я создал новую DLL, которая использовала GetModuleHandleEx и GetModuleFileName для определения имени загруженной DLL и записи его в текстовый файл.
Моя следующая цель состояла в том, чтобы проанализировать CSV-файл на наличие в списке путей к DLL, просмотреть этот список, скопировать мою тестовую DLL по указанному пути, запустить целевой процесс, остановить целевой процесс и удалить тестовую DLL. Если тестовая DLL была успешно загружена, она запишет свое имя в результирующий файл.
Когда этот процесс завершится, у меня будет список возможных перехватов DLL (я надеюсь), записанных в текстовый файл.
Всю магию в моем проекте DLLHijackTest творит скрипт PowerShell. Он принимает путь к CSV-файлу, сгенерированному ProcMon, путь к вашей вредоносной DLL, путь к процессу, который вы хотите запустить, и любые аргументы, которые вы хотите передать процессу.
Параметры Get-PotentialDLLHijack
Get-PotentialDLLHijack.ps1
Через несколько минут я проверяю текстовый файл, указанный в моей «вредоносной» DLL, на предмет возможных перехватов DLL. Я обнаружил следующие возможные пути перехвата для Slack:
PS C:Users\John\Desktop> Get-PotentialDLLHijack -CSVPath .\Logfile.CSV -MaliciousDLLPath .\DLLHijackTest.dll -ProcessPath "C:\Users\John\AppData\Local\slack\slack.exe"
C:\Users\John\AppData\Local\slack\app-4.6.0\WINSTA.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\LINKINFO.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\ntshrui.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\srvcli.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\cscapi.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\KBDUS.DLL
На примере Microsoft Teams
Выполняем описанный выше процесс еще раз:
- Используйте ProcMon для выявления потенциальных путей перехвата DLL, экспортируйте эти данные в виде CSV файла.
- Определите путь запуска процесса.
- Определите любые аргументы, которые вы хотите передать процессу.
- Запустите Get-PotentialDLLHijack.ps1 с соответствующими аргументами.
Я обнаружил следующие возможные пути перехвата для Microsoft Teams:
PS C:Users\John\Desktop> Get-PotentialDLLHijack -CSVPath .\Logfile.CSV -MaliciousDLLPath .\DLLHijackTest.dll -ProcessPath "C:\Users\John\AppData\Local\Microsoft\Teams\Update.exe" -ProcessArguments '--processStart "Teams.exe"'
C:\Users\John\AppData\Local\Microsoft\Teams\current\WINSTA.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\LINKINFO.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\ntshrui.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\srvcli.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\cscapi.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\WindowsCodecs.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\TextInputFramework.dll
Примечание: Мне пришлось внести небольшие изменения в скрипт PowerShell, чтобы завершить Teams.exe, так как мой скрипт пытается завершить процесс, который он пытался запустить, в данном случае это Update.exe.
На примере Visual Studio Code
Повторяя описанный выше процесс, я обнаружил следующие потенциальные пути перехвата для Visual Studio Code:
PS C:Users\John\Desktop> Get-PotentialDLLHijack -CSVPath .\Logfile.CSV -MaliciousDLLPath .\DLLHijackTest.dll -ProcessPath "C:\Users\John\AppData\Local\Programs\Microsoft VS Code\Code.exe"
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\WINSTA.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\LINKINFO.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\ntshrui.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\srvcli.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\cscapi.dll
Подмена общих (shared) DLL
Я заметил, что Slack, Microsoft Teams и Visual Studio Code совместно используют следующие DLL:
- WINSTA.dll
- LINKINFO.dll
- ntshrui.dll
- srvcli.dll
- cscapi.dll
Мне это показалось интересным, и я хотел понять, что вызывает такое поведение.
Методология: понимание путей перехвата общих DLL
Я следил за стек трейсом, когда Slack пытался загрузить WINSTA.dll, LINKINFO.dll, ntshrui.dll, srvcli.dll и cscapi.dll.
DLL с отложенной загрузкой
Я заметил сходство в стек трейсе при загрузке WINSTA.dll, LINKINFO.dll, ntshrui.dll и srvcli.dll.
Стек трейс, когда Code.exe пытается загрузить WINSTA.dll
Стек трейс, когда Teams.exe пытается загрузить LINKINFO.dll,
Стек трейс, когда Slack пытается загрузить ntshrui.dll
Стек трейс постоянно содержит вызов _tailMerge_<dllname>_dll, delayLoadHelper2 за которым следует LdrResolveDelayLoadedAPI. Такое поведение было одинаковым для всех трех приложений.
Я определил, что это поведение связано с отложенной загрузкой DLL. Из стек трейса при загрузке WINSTA.dll я мог видеть, что модулем, ответственным за эту отложенную загрузку, был wtsapi32.dll.
Я открыл wtsapi32.dll в Ghidra и использовал Search -> For Strings -> Filter: WINSTA.dll. Двойной клик по найденной строке приведет вас к ее локации в памяти.
Строка «WINSTA.dll» в wtsapi32.dll
Кликнув правой кнопкой мыши по локации в памяти, мы сможем найти любые ссылки на этот адрес.
Ссылки на WINSTA.dll
Следуя ссылкам, мы видим, что строка WINSTA.dll передается в структуру с именем ImgDelayDescr. Глядя на документацию по этой структуре, мы можем подтвердить, что она связана с отложенной загрузкой DLL.
typedef struct ImgDelayDescr {
DWORD grAttrs; // атрибуты
RVA rvaDLLName; // RVA в имя dll
RVA rvaHmod; // RVA дескриптора модуля
RVA rvaIAT; // RVA IAT
RVA rvaINT; // RVA INT
RVA rvaBoundIAT; // RVA опциональной привязки IAT
RVA rvaUnloadIAT; // RVA опциональной копии оригинального IAT
DWORD dwTimeStamp; // 0, если не привязано,
// O.W. дата/таймстемп DLL, привязанной к (Old BIND)
} ImgDelayDescr, * PImgDelayDescr;
Эту структуру можно передать в __delayLoadHelper2, который будет использовать LoadLibrary/GetProcAddress для загрузки указанной DLL и исправления адреса импортируемой функции в таблице адресов импорта отложенной загрузки (IAT).
FARPROC WINAPI __delayLoadHelper2(
PCImgDelayDescr pidd, // Константный указатель на структуру ImgDelayDescr
FARPROC * ppfnIATEntry // Указатель на слот в IAT отложенной загрузки
);
Найдя другие ссылки на нашу структуру ImgDelayDescr, мы можем найти вызов __delayLoadHelper2, который затем вызывает ResolveDelayLoadedAPI. Я переименовал имя функции, типы и переменные, чтобы облегчить понимание.
__delayLoadHelper2 и ResolveDelayLoadedAPI в Ghidra
Отлично! Это соответствует тому, что мы видели в нашем ProcMon стек трейсе, когда Slack пытался загрузить WINSTA.dll.
__delayLoadHelper2 и ResolveDelayLoadedAPI в ProcMon.
Такое поведение было единообразно для WINSTA.dll, LINKINFO.dll, ntshrui.dll и srvcli.dll. Основным отличием каждой DLL с отложенной загрузкой была «родительская» DLL. Во всех трех приложениях:
- wtsapi32.dll отложено загружала WINSTA.dll
- shell32.dll отложенно загружала LINKINFO.dll
- LINKINFO.dll отложено загружала ntshrui.dll
- ntshrui.dll отложено загружала srvcli.dll
Заметили что-нибудь интересное? Похоже, что shell32.dll загружает LINKINFO.dll, который загружает ntshrui.dll, который, наконец, загружает srvcli.dll. Это подводит нас к нашему последнему общему потенциальному варианту подмены DLL — cscapi.dll.
Подмена DLL в NetShareGetInfo и NetShareEnum
Я следил за стек трейсом, когда Slack пытался загрузить cscapi.dll и видел вызов LoadLibraryExW, который, по-видимому, исходил из srvcli.dll.
Стек трейс при загрузке cscapi.dll
Я открыл srvcli.dll в Ghidra и использовал Search -> For Strings -> Filter: cscapi.dll. Двойной клик по найденной строке и переход по ссылкам приводит к ожидаемому LoadLibrary вызову.
srvcli.dll вызывает LoadLibrary для cscapi.dll
Переименовав функцию, содержащую вызов LoadLibrary, и проследовав по ссылкам, я получил два места использования функции:
NetShareEnum загружает cscapi.dll
NetShareGetInfo загружает cscapi.dll
Я проверил это с помощью РоС программ, которые вызывали NetShareEnum и NetShareGetInfo:
NetShareEnum.exe загружает cscapi.dll
NetShareGetInfo.exe загружает cscapi.dll
Результаты
В Slack доступны следующие пути подмены DLL:
C:\Users\John\AppData\Local\slack\app-4.6.0\WINSTA.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\LINKINFO.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\ntshrui.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\srvcli.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\cscapi.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\KBDUS.DLL
В Microsoft Teams доступны следующие пути подмены DLL:
C:\Users\John\AppData\Local\Microsoft\Teams\current\WINSTA.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\LINKINFO.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\ntshrui.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\srvcli.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\cscapi.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\WindowsCodecs.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\TextInputFramework.dll
В Visual Studio Code доступны следующие пути подмены DLL:
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\WINSTA.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\LINKINFO.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\ntshrui.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\srvcli.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\cscapi.dll
Кроме того, я обнаружил, что программы, использующие NetShareEnum и NetShareGetInfo, предоставляют возможность подмены DLL в форме cscapi.dll из-за жестко захардкоженного вызова LoadLibrary. Я подтвердил это поведение с помощью Ghidra и PoC.
Заключение
Напомним, что перехват DLL — это метод, с помощью которого злоумышленники могут повлиять на выполнение кода в подписанных/доверенных приложениях. Я создал инструменты, помогающие автоматизировать обнаружение путей перехвата DLL. Используя этот инструмент, я обнаружил пути перехвата DLL в Slack, Microsoft Teams и Visual Studio Code.
Я заметил, что пути перехвата DLL этих трех приложений частично совпадают, и исследовал причину. Я осветил свою методику понимания данного совпадения. Я узнал о DLL с отложенной загрузкой и обнаружил два вызова API, которые делают возможным перехват DLL в любой программе, которая их вызывает:
- NetShareEnum загружает cscapi.dll
- NetShareGetInfo загружает cscapi.dll
Спасибо, что нашли время, чтобы прочитать эту статью, надеюсь, вы узнали кое-что новое о Windows API, Ghidra, ProcMon, DLL и перехвате DLL!
Ссылки
Большой привет моим коллегам Дэниелу Хейнсену (@hotnops), Ли Кристенсену (@tifkin_) и Мэтту Хэнду(@matterpreter) за то, что они помогли справиться с Ghidra/ProcMon!
Проверка публичных PoC для использования при пентесте
Читать ещё:
- Итак, вы хотите стать аналитиком в области сетевой безопасности…
- JWT: Атака на цифровую подпись VS MAC-атака
- Побег из привилегированных Docker-контейнеров
===========
Источник:
habr.com
===========
===========
Автор оригинала: Justin Bui
===========Похожие новости:
- [Информационная безопасность, Реверс-инжиниринг] Руткиты на основе BIOS. Часть 2 (перевод)
- [Информационная безопасность, Криптография] Какова оптимальная длина пароля? (перевод)
- [Python, Программирование, Разработка под Windows] Создание голосового ассистента на Python, часть 1
- [Тестирование IT-систем, Программирование, Софт] Что такое CI/CD? Разбираемся с непрерывной интеграцией и непрерывной поставкой (перевод)
- [Информационная безопасность, Старое железо, Транспорт] Pen Test Partners: обновления ПО самолётов Boeing 747 поставлялись на дискетах
- [Информационная безопасность] Вы просили подсказку? Мы ее вам дадим
- [Разработка под Windows] Создаем EXE
- [Информационная безопасность] Приватность в Telegram
- [Информационная безопасность, Гаджеты] В чипе Qualcomm Snapdragon нашли более 400 уязвимостей
- [Информационная безопасность, Беспроводные технологии] Атака недели: голосовые звонки в LTE (ReVoLTE) (перевод)
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_razrabotka_pod_windows (Разработка под Windows), #_windows, #_red_team, #_dll, #_dll_hijacking, #_automation, #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_razrabotka_pod_windows (
Разработка под Windows
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:31
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Привет, хабровчане. Прямо сейчас открыт набор на новый поток курса «Пентест. Практика тестирования на проникновение». В преддверии старта курса делимся с вами переводом интересного материала. Введение В этой статье мы рассмотрим концепцию перехвата порядка поиска динамически подключаемых библиотек (DLL hijacking) и то, как она может быть использована для достижения устойчивости (persistence) в юзерленде в системах Windows. Этот метод описан в MITER ATT&CK в разделе: «Перехват порядка поиска DLL (T1038)». Подмена DLL может быть использована злоумышленниками для множества разных целей, но в этой статье основное внимание будет уделено достижению устойчивости с помощью приложений с автозапуском. Например, поскольку Slack и Microsoft Teams запускаются при загрузке (по умолчанию), подмена DLL в одном из этих приложений позволит злоумышленнику получить устойчивый доступ к своей цели — всякий раз, когда пользователь входит в систему. После представления концепции DLL, порядка поиска DLL, и подмены DLL, я раскрою процесс автоматизации обнаружения возможности перехвата DLL. В этой статье будет рассказано об обнаружении путей перехвата DLL в Slack, Microsoft Teams и Visual Studio Code. Наконец, я обнаружил несколько путей перехвата DLL, которые использовались разными приложениями, исследовал основную причину и обнаружил, что приложения, использующие определенные вызовы API Windows, подвержены перехвату DLL, когда не работают из C:\Windows\System32\. Я хочу поблагодарить своего коллегу Джозайю Массари (@Airzero24) за то, что он первым обнаружил некоторые из этих перехватов DLL, объяснил их методологию и вдохновил меня автоматизировать обнаружение. Что такое DLL? DLL — это библиотека, содержащая код и данные, которые могут использоваться одновременно более чем одной программой. (Сурс) Функциональные возможности DLL могут быть использованы приложением Windows с помощью одной из функций LoadLibrary*. Приложения могут ссылаться на DLL, разработанные специально для этих приложений, или DLL Windows, уже находящиеся на диске в System32. Разработчики могут загружать DLL из System32, чтобы использовать в своих приложениях функционал, уже реализованный в Windows, без необходимости писать этот функционал с нуля. Например, разработчик, которому необходимо выполнять HTTP-запросы, может использовать библиотеку WinHTTP (winhttp.dll) вместо реализации HTTP-запросов с использованием сырых сокетов. Порядок поиска DLL и перехват Поскольку DLL существуют в виде файлов на диске, вы можете задаться вопросом, как приложение узнает, откуда загружать DLL? Microsoft подробно задокументировала порядок поиска DLL здесь. Начиная с Windows XP SP2, безопасный режим поиска DLL включен по умолчанию (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode). При включенном безопасном режиме порядок поиска DLL следующий:
Система может содержать несколько версий одной и той же DLL. Приложения могут управлять выбором расположения, из которого должен загружается DLL, путем указания полного пути или использования другого механизма, такого как манифест. (Сурс) Если приложение не указывает, откуда загружать DLL, Windows использует порядок поиска DLL по умолчанию, приведенный выше. Первая позиция в порядке поиска DLL (каталог, из которого загружается приложение) представляет интерес для злоумышленников. Если разработчик приложения предполагает загрузку DLL из C:\Windows\System32, но явно не прописал это в приложении, вредоносная DLL, помещенная в каталог приложения, будет загружена раньше, чем легитимная DLL из System32. Загрузка вредоносной DLL называется подменой (или перехватом) DLL и используется злоумышленниками для загрузки вредоносного кода в доверенные/подписанные приложения. Использование подмены DLL для достижения устойчивости Подмена DLL может использоваться для достижения устойчивости, когда уязвимое приложение/служба запускается и вредоносная DLL размещается в уязвимом месте. Мой коллега, @Airzero24, обнаружил подмену DLL в Microsoft OneDrive, Microsoft Teams и Slack в виде userenv.dll. Именно эти программы стали целью перехвата, потому что по умолчанию они настроены на запуск при загрузке Windows. Это можно увидеть ниже в диспетчере задач:  Приложения Windows, настроенные на автозапуск Чтобы проверить подмену DLL, я создал загрузчик шеллкода DLL, который запускал Cobalt Strike Beacon. Я переименовал вредоносную DLL в userenv.dll и скопировал ее в каталог уязвимого приложения. Я запустил приложение и увидел свой новый Beacon коллбек.  Cobalt Strike Beacon через перехват DLL Используя Process Explorer, я могу проверить, действительно ли моя вредоносная DLL была загружена уязвимым приложением.  Обозреватель процессов, показывающий загруженную вредоносную DLL Автоматическое обнаружение возможности перехвата DLL После подтверждения ранее известного перехвата DLL, я хотел проверить, смогу ли я найти другие возможности для подмены DLL, которые можно было бы эксплуатировать. Код, использованный в моих проверка, можно найти здесь: https://github.com/slyd0g/DLLHijackTest На примере Slack Чтобы начать этот процесс, я запустил Process Monitor (ProcMon) со следующими фильтрами:
 Поиск отсутствующих DLL в ProcMon. Затем я запустил Slack и изучил ProcMon на предмет любых DLL, которые Slack искал, но не смог найти.  Возможные пути перехвата DLL, обнаруженные с помощью ProcMon Я экспортировал эти данные из ProcMon в виде CSV файла для облегчения парсинга в PowerShell. С моей текущей DLL загрузчика шелл-кода я не смог бы легко определить имена DLL, которые были успешно загружены Slack. Я создал новую DLL, которая использовала GetModuleHandleEx и GetModuleFileName для определения имени загруженной DLL и записи его в текстовый файл. Моя следующая цель состояла в том, чтобы проанализировать CSV-файл на наличие в списке путей к DLL, просмотреть этот список, скопировать мою тестовую DLL по указанному пути, запустить целевой процесс, остановить целевой процесс и удалить тестовую DLL. Если тестовая DLL была успешно загружена, она запишет свое имя в результирующий файл. Когда этот процесс завершится, у меня будет список возможных перехватов DLL (я надеюсь), записанных в текстовый файл. Всю магию в моем проекте DLLHijackTest творит скрипт PowerShell. Он принимает путь к CSV-файлу, сгенерированному ProcMon, путь к вашей вредоносной DLL, путь к процессу, который вы хотите запустить, и любые аргументы, которые вы хотите передать процессу.  Параметры Get-PotentialDLLHijack  Get-PotentialDLLHijack.ps1 Через несколько минут я проверяю текстовый файл, указанный в моей «вредоносной» DLL, на предмет возможных перехватов DLL. Я обнаружил следующие возможные пути перехвата для Slack: PS C:Users\John\Desktop> Get-PotentialDLLHijack -CSVPath .\Logfile.CSV -MaliciousDLLPath .\DLLHijackTest.dll -ProcessPath "C:\Users\John\AppData\Local\slack\slack.exe"
C:\Users\John\AppData\Local\slack\app-4.6.0\WINSTA.dll C:\Users\John\AppData\Local\slack\app-4.6.0\LINKINFO.dll C:\Users\John\AppData\Local\slack\app-4.6.0\ntshrui.dll C:\Users\John\AppData\Local\slack\app-4.6.0\srvcli.dll C:\Users\John\AppData\Local\slack\app-4.6.0\cscapi.dll C:\Users\John\AppData\Local\slack\app-4.6.0\KBDUS.DLL На примере Microsoft Teams Выполняем описанный выше процесс еще раз:
Я обнаружил следующие возможные пути перехвата для Microsoft Teams: PS C:Users\John\Desktop> Get-PotentialDLLHijack -CSVPath .\Logfile.CSV -MaliciousDLLPath .\DLLHijackTest.dll -ProcessPath "C:\Users\John\AppData\Local\Microsoft\Teams\Update.exe" -ProcessArguments '--processStart "Teams.exe"'
C:\Users\John\AppData\Local\Microsoft\Teams\current\WINSTA.dll C:\Users\John\AppData\Local\Microsoft\Teams\current\LINKINFO.dll C:\Users\John\AppData\Local\Microsoft\Teams\current\ntshrui.dll C:\Users\John\AppData\Local\Microsoft\Teams\current\srvcli.dll C:\Users\John\AppData\Local\Microsoft\Teams\current\cscapi.dll C:\Users\John\AppData\Local\Microsoft\Teams\current\WindowsCodecs.dll C:\Users\John\AppData\Local\Microsoft\Teams\current\TextInputFramework.dll Примечание: Мне пришлось внести небольшие изменения в скрипт PowerShell, чтобы завершить Teams.exe, так как мой скрипт пытается завершить процесс, который он пытался запустить, в данном случае это Update.exe.
На примере Visual Studio Code Повторяя описанный выше процесс, я обнаружил следующие потенциальные пути перехвата для Visual Studio Code: PS C:Users\John\Desktop> Get-PotentialDLLHijack -CSVPath .\Logfile.CSV -MaliciousDLLPath .\DLLHijackTest.dll -ProcessPath "C:\Users\John\AppData\Local\Programs\Microsoft VS Code\Code.exe"
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\WINSTA.dll C:\Users\John\AppData\Local\Programs\Microsoft VS Code\LINKINFO.dll C:\Users\John\AppData\Local\Programs\Microsoft VS Code\ntshrui.dll C:\Users\John\AppData\Local\Programs\Microsoft VS Code\srvcli.dll C:\Users\John\AppData\Local\Programs\Microsoft VS Code\cscapi.dll Подмена общих (shared) DLL Я заметил, что Slack, Microsoft Teams и Visual Studio Code совместно используют следующие DLL:
Мне это показалось интересным, и я хотел понять, что вызывает такое поведение. Методология: понимание путей перехвата общих DLL Я следил за стек трейсом, когда Slack пытался загрузить WINSTA.dll, LINKINFO.dll, ntshrui.dll, srvcli.dll и cscapi.dll. DLL с отложенной загрузкой Я заметил сходство в стек трейсе при загрузке WINSTA.dll, LINKINFO.dll, ntshrui.dll и srvcli.dll.  Стек трейс, когда Code.exe пытается загрузить WINSTA.dll  Стек трейс, когда Teams.exe пытается загрузить LINKINFO.dll,  Стек трейс, когда Slack пытается загрузить ntshrui.dll Стек трейс постоянно содержит вызов _tailMerge_<dllname>_dll, delayLoadHelper2 за которым следует LdrResolveDelayLoadedAPI. Такое поведение было одинаковым для всех трех приложений. Я определил, что это поведение связано с отложенной загрузкой DLL. Из стек трейса при загрузке WINSTA.dll я мог видеть, что модулем, ответственным за эту отложенную загрузку, был wtsapi32.dll. Я открыл wtsapi32.dll в Ghidra и использовал Search -> For Strings -> Filter: WINSTA.dll. Двойной клик по найденной строке приведет вас к ее локации в памяти.  Строка «WINSTA.dll» в wtsapi32.dll Кликнув правой кнопкой мыши по локации в памяти, мы сможем найти любые ссылки на этот адрес.  Ссылки на WINSTA.dll Следуя ссылкам, мы видим, что строка WINSTA.dll передается в структуру с именем ImgDelayDescr. Глядя на документацию по этой структуре, мы можем подтвердить, что она связана с отложенной загрузкой DLL. typedef struct ImgDelayDescr {
DWORD grAttrs; // атрибуты RVA rvaDLLName; // RVA в имя dll RVA rvaHmod; // RVA дескриптора модуля RVA rvaIAT; // RVA IAT RVA rvaINT; // RVA INT RVA rvaBoundIAT; // RVA опциональной привязки IAT RVA rvaUnloadIAT; // RVA опциональной копии оригинального IAT DWORD dwTimeStamp; // 0, если не привязано, // O.W. дата/таймстемп DLL, привязанной к (Old BIND) } ImgDelayDescr, * PImgDelayDescr; Эту структуру можно передать в __delayLoadHelper2, который будет использовать LoadLibrary/GetProcAddress для загрузки указанной DLL и исправления адреса импортируемой функции в таблице адресов импорта отложенной загрузки (IAT). FARPROC WINAPI __delayLoadHelper2(
PCImgDelayDescr pidd, // Константный указатель на структуру ImgDelayDescr FARPROC * ppfnIATEntry // Указатель на слот в IAT отложенной загрузки ); Найдя другие ссылки на нашу структуру ImgDelayDescr, мы можем найти вызов __delayLoadHelper2, который затем вызывает ResolveDelayLoadedAPI. Я переименовал имя функции, типы и переменные, чтобы облегчить понимание.  __delayLoadHelper2 и ResolveDelayLoadedAPI в Ghidra Отлично! Это соответствует тому, что мы видели в нашем ProcMon стек трейсе, когда Slack пытался загрузить WINSTA.dll.  __delayLoadHelper2 и ResolveDelayLoadedAPI в ProcMon. Такое поведение было единообразно для WINSTA.dll, LINKINFO.dll, ntshrui.dll и srvcli.dll. Основным отличием каждой DLL с отложенной загрузкой была «родительская» DLL. Во всех трех приложениях:
Заметили что-нибудь интересное? Похоже, что shell32.dll загружает LINKINFO.dll, который загружает ntshrui.dll, который, наконец, загружает srvcli.dll. Это подводит нас к нашему последнему общему потенциальному варианту подмены DLL — cscapi.dll. Подмена DLL в NetShareGetInfo и NetShareEnum Я следил за стек трейсом, когда Slack пытался загрузить cscapi.dll и видел вызов LoadLibraryExW, который, по-видимому, исходил из srvcli.dll.  Стек трейс при загрузке cscapi.dll Я открыл srvcli.dll в Ghidra и использовал Search -> For Strings -> Filter: cscapi.dll. Двойной клик по найденной строке и переход по ссылкам приводит к ожидаемому LoadLibrary вызову.  srvcli.dll вызывает LoadLibrary для cscapi.dll Переименовав функцию, содержащую вызов LoadLibrary, и проследовав по ссылкам, я получил два места использования функции:  NetShareEnum загружает cscapi.dll  NetShareGetInfo загружает cscapi.dll Я проверил это с помощью РоС программ, которые вызывали NetShareEnum и NetShareGetInfo:  NetShareEnum.exe загружает cscapi.dll  NetShareGetInfo.exe загружает cscapi.dll Результаты В Slack доступны следующие пути подмены DLL: C:\Users\John\AppData\Local\slack\app-4.6.0\WINSTA.dll
C:\Users\John\AppData\Local\slack\app-4.6.0\LINKINFO.dll C:\Users\John\AppData\Local\slack\app-4.6.0\ntshrui.dll C:\Users\John\AppData\Local\slack\app-4.6.0\srvcli.dll C:\Users\John\AppData\Local\slack\app-4.6.0\cscapi.dll C:\Users\John\AppData\Local\slack\app-4.6.0\KBDUS.DLL В Microsoft Teams доступны следующие пути подмены DLL: C:\Users\John\AppData\Local\Microsoft\Teams\current\WINSTA.dll
C:\Users\John\AppData\Local\Microsoft\Teams\current\LINKINFO.dll C:\Users\John\AppData\Local\Microsoft\Teams\current\ntshrui.dll C:\Users\John\AppData\Local\Microsoft\Teams\current\srvcli.dll C:\Users\John\AppData\Local\Microsoft\Teams\current\cscapi.dll C:\Users\John\AppData\Local\Microsoft\Teams\current\WindowsCodecs.dll C:\Users\John\AppData\Local\Microsoft\Teams\current\TextInputFramework.dll В Visual Studio Code доступны следующие пути подмены DLL: C:\Users\John\AppData\Local\Programs\Microsoft VS Code\WINSTA.dll
C:\Users\John\AppData\Local\Programs\Microsoft VS Code\LINKINFO.dll C:\Users\John\AppData\Local\Programs\Microsoft VS Code\ntshrui.dll C:\Users\John\AppData\Local\Programs\Microsoft VS Code\srvcli.dll C:\Users\John\AppData\Local\Programs\Microsoft VS Code\cscapi.dll Кроме того, я обнаружил, что программы, использующие NetShareEnum и NetShareGetInfo, предоставляют возможность подмены DLL в форме cscapi.dll из-за жестко захардкоженного вызова LoadLibrary. Я подтвердил это поведение с помощью Ghidra и PoC. Заключение Напомним, что перехват DLL — это метод, с помощью которого злоумышленники могут повлиять на выполнение кода в подписанных/доверенных приложениях. Я создал инструменты, помогающие автоматизировать обнаружение путей перехвата DLL. Используя этот инструмент, я обнаружил пути перехвата DLL в Slack, Microsoft Teams и Visual Studio Code. Я заметил, что пути перехвата DLL этих трех приложений частично совпадают, и исследовал причину. Я осветил свою методику понимания данного совпадения. Я узнал о DLL с отложенной загрузкой и обнаружил два вызова API, которые делают возможным перехват DLL в любой программе, которая их вызывает:
Спасибо, что нашли время, чтобы прочитать эту статью, надеюсь, вы узнали кое-что новое о Windows API, Ghidra, ProcMon, DLL и перехвате DLL! Ссылки Большой привет моим коллегам Дэниелу Хейнсену (@hotnops), Ли Кристенсену (@tifkin_) и Мэтту Хэнду(@matterpreter) за то, что они помогли справиться с Ghidra/ProcMon! Проверка публичных PoC для использования при пентесте Читать ещё:
=========== Источник: habr.com =========== =========== Автор оригинала: Justin Bui ===========Похожие новости:
Блог компании OTUS. Онлайн-образование ), #_informatsionnaja_bezopasnost ( Информационная безопасность ), #_razrabotka_pod_windows ( Разработка под Windows ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:31
Часовой пояс: UTC + 5