Оригинал статьи публикуется с разрешения автора.

Ссылка: https://www.freebuf.com/defense/397357.html.

0X00Предисловие

Делать мне было нечего, и я за один присест прочитал список распространённых методов повышения привилегий Windows, написанный мастером Наньчэном, вспомнил статьи, на которые недавно подписался, опыт стрельбы HTB и тестирования на проникновение, и попытался расширить границы своих знаний. поэтому я придумал эту статью. Повышение авторитета для красной команды — то же самое, что сычуаньская кухня для Хуацзяо. Когда я работал инженером по тестированию на проникновение, я обнаружил, что локальные методы повышения привилегий Windows были разделены на две категории из-за проблем окружающей среды (среда домена и рабочая группа). Из-за особенностей Windows существуют большие различия в методах атаки между доменными средами и рабочими группами, поэтому нам необходимо относиться к ним по-разному в зависимости от фактической среды теста на проникновение.

В разделе повышения привилегий рабочей группы большое количество локальных методов повышения привилегий вызвано доступными для записи каталогами в переменных среды системного пути и переполнением памяти операционной системы. Коренными причинами этих угроз являются распространенные ошибки конфигурации корпоративной системы, а также версия или сборка операционной системы, используемая предприятием, что значительно снижает порог выявления и использования этих проблем.

В разделе, посвященном среде домена, автор представит распространенные локальные методы повышения привилегий среди красных команд, то есть использование повышения привилегий ретрансляции NTLM в среде домена Windows и протокола Kerberos в среде домена для проведения атак с целью повышения разрешений сотрудника. рабочие станции.

0X01 Проблема с настройкой каталога системного пути (рабочая группа)

Для предприятий со зрелыми и полными решениями для мониторинга безопасности, если они хотят успешно использовать уязвимости для получения высоких привилегий, трудно избежать запуска обнаружения в конечных точках предприятия и продуктах сетевого мониторинга. В настоящее время локальные операции по повышению привилегий требуют более скрытного подхода. и надежный метод. Проблема с настройкой каталога системного пути (рабочая группа) — это локальный метод повышения привилегий Windows, который автор часто использует на позициях тестирования на проникновение. Этот метод очень распространен в многопользовательских системах с множеством установленных приложений.

Так в чем же проблема с настройкой каталога системного пути? Ответ: Это вызвано неправильно настроенными приложениями или скриптами, которые позволяют пользователям осуществлять запись в каталоги с ограниченным доступом. Например, если веб-приложение позволяет пользователям загружать файлы и приложение не проверяет должным образом целевой каталог для загружаемых файлов, злоумышленник может загружать файлы в каталог с ограниченным доступом.

Например: В ходе эксперимента, показанного на рисунке 3, мы обнаружили, что после создания двух папок с именем test в C:\Program Files\test и C:\test создайте непривилегированного пользователя и попытайтесь разрешить непривилегированному пользователю писать в эти две папки. каталог. Существует значительная разница в наследуемых разрешениях каталогов, созданных в каталоге C:\Program Files, и каталогов, созданных в каталоге C:\. Непривилегированные пользователи могут писать в C:\test\, но не могут писать в C:\Program Files\test\, то есть разрешения для каталога C:\Program Files по умолчанию более строгие, чем разрешения для каталога C:\.

C:\Directory (рис. 1): 1. По умолчанию группа «Прошедшие проверку» имеет разрешение на создание файлов и папок. 2. Это разрешение является наследуемым, что означает, что оно применяется ко всем созданным файлам, которые явно не запрещают его. Содержание; . Каталог C:\Program Files (рис. 2): 1. По умолчанию права группы «Прошедшие проверку» на создание файлов и папок не включены. 2. Папки, созданные в «Program Files», по умолчанию блокируют непривилегированные пользователи. это.

Рисунок 1 (исходное изображение преторианца)

Рисунок 2 (исходное изображение преторианца)

Рисунок 3 (исходное изображение преторианца)

Загрузка неопубликованной библиотеки 0X02DLL (рабочая группа)

Обычный процесс неопубликованной загрузки DLL заключается в следующем: злоумышленник сначала изменяет ключ реестра, чтобы он указывал на вредоносную DLL, использует социальную инженерию (по электронной почте, в социальных сетях или других каналах), чтобы приблизиться к цели атаки, и отправляет вредоносная DLL и использует риторику, чтобы побудить жертву Запустить приложение. Когда цель запускает намеченную программу, приложение попытается загрузить DLL по пути, указанному в разделе реестра. Поскольку ключ реестра был изменен, приложение будет. загрузить вредоносную DLL и выполнить ее код. (Как показано на рисунке 4 ниже)

Рисунок 4

За время своей карьеры в красной команде я использовал этот метод фишинга для получения локальных разрешений высокого уровня от цели, в значительной степени избегая риска быть обнаруженным оборудованием корпоративной безопасности. В соответствии с правилами Microsoft необходимо отметить, что поведение загрузки неопубликованных DLL может не вызвать предупреждение об уязвимости в системе Windows, поскольку система выполняет правильную операцию по поиску пути. Однако если сторонний установщик приложения изменяет переменную среды системного пути во время установки и создает проблемы с разрешениями пути для записи, Защитник может обнаружить это и предупредить пользователя. Поэтому, если красной команде необходимо прикрыть свои атаки, то наиболее интересными целями для злоумышленников являются собственные продукты Microsoft.

Самый прямой способ использовать неопубликованную загрузку DLL для повышения привилегий — это идентифицировать службу приложения, работающую как NT AUTHORITY\SYSTEM, которая пытается загрузить несуществующую DLL (динамически подключаемую библиотеку) или пытается выполнить несуществующий исполняемый файл. Служба может попытаться загрузить файл DLL, который существует только в настольных операционных системах. Поскольку файл не существует в операционной системе сервера, в конечном итоге он будет проходить системный путь в поисках файла. С оперативной точки зрения, лучший сценарий для злоумышленника заключается в том, что непривилегированному пользователю не нужно перезагружать целевую систему, чтобы инициировать это действие.

Рисунок 5 (источник изображения)

Например: Целевое фишинговое электронное письмо, показанное на рисунке 5, содержит вложение, использующее контроль уязвимостей (CVE-2012-0158) в Windows ActiveX. Оно выглядит как обычный двоичный файл, но в сочетании с ним оно становится исполняемым вредоносным файлом. Как показано на рисунке, зеленый значок представляет собой обычный исполняемый файл, содержащий уязвимость неопубликованной загрузки DLL. oinfop11.exe будет представлен после обновления версии службы Office 2003. Эта направленная фишинговая атака загружает мошеннический компонент DLL (Oinfo11.ocx). После загрузки Oinfo.ocx в память он автоматически распаковывает, загружает и декодирует вспомогательный компонент (Oinfo11.iso).

0X03Win32k Повышение привилегий (рабочая группа)

Повышение привилегий Win32k — хороший локальный метод повышения привилегий, и диапазон его воздействия очень велик, включая подсистему Win32k в Windows 8, Windows 10 и Windows Server. Пользователи с низкими привилегиями могут относительно легко получить системные привилегии в Windows, воспользовавшись уязвимостями повышения привилегий Win32k. Уязвимость находится в подсистеме Win32k (т. е. драйвере ядра Win32k.sys), которая управляет оконным менеджером операционной системы, выводом на экран, вводом и графикой.

Было обнаружено, что подсистема Win32k заблокировала только объект окна, но не смогла заблокировать вложенный объект меню. Причина проблемы такого типа заключается в том, что код старой версии копируется в новую версию Win32k. Если у злоумышленника есть разрешение на изменение определенного адреса в системной памяти, объект меню может быть подделан или захвачен. Взяв под контроль объект меню, злоумышленник может получить тот же уровень доступа, что и программа, запустившая его (обычно системные разрешения). Исследователи на Github опубликовали PoC для повышения привилегий Win32k (ссылка на Win32kpoc), которое позволяет повысить привилегии до системного уровня, что значительно снижает порог использования этой уязвимости. Эта версия POC обычно не требует новых методов эксплуатации, кроме изучения различных способов управления первой операцией записи с использованием освобожденных данных, которые повторно занимают память. Хотя повышение привилегий Win32k, по-видимому, невозможно использовать в версии системы Windows 11, оно представляет значительный риск для корпоративных систем (сегодняшние предприятия по-прежнему используют Windows 10 в качестве основной офисной системы). Более того, уязвимость повышения привилегий Win32k во многом связана с утечкой адреса дескриптора кучи рабочего стола. Если у предприятия нет разумного решения, информационная безопасность предприятия по-прежнему будет подвергаться большим рискам. Это хорошее локальное повышение привилегий. значит красная команда.

Исследование автора проводилось на Windows Server 2016. Благодаря онлайн-блогам по анализу уязвимостей и исследованию исправлений уязвимостей автор обнаружил довольно интересную проблему. Судя по всему, код уязвимости заключается в том, что счетчик ссылок на конкретный объект увеличился несколько раз (рис. 6). Из-за древней природы кода win32k автор может лишь повысить убедительность, перечислив некоторые ранние комментарии к исходному коду (). Рисунок 7). Реализация кода Win32k фокусируется только на блокировке объекта окна и непреднамеренно игнорирует блокировку объекта меню, вложенного в объект окна. Так как же происходит неверная ссылка на объект меню в этом окне? Автор проанализировал контекст функции уязвимости (рис. 8 и рис. 9). В процессе анализа автор обнаружил проблему, на которую стоит обратить внимание. Хотя меню, передаваемые в xxxEnableMenuItem(), обычно блокируются в функциях более высокого уровня, определение того, какой именно объект меню следует защитить в этом конкретном случае, представляет собой вопрос, который необходимо определить. Продолжая углубленно анализировать функцию xxxEnableMenuItem, автор внимательно изучил потенциальную обработку объектов меню и обнаружил важную проблему: меню, возвращаемое функцией MenuItemState, может не только содержать главное меню внутри окна, но также может быть расширено до подменю. В некоторых случаях следующее можно даже расширить до подменю.

Рисунок 6 (источник изображения)

Рисунок 7 (источник изображения)

Рисунок 8 (источник изображения)

Рисунок 9 (источник изображения)

При эксплуатации уязвимостей повышения привилегий Win32k необходимо выполнить предварительную оценку, чтобы избежать ситуаций, которые невозможно обойти, что позволяет сэкономить много времени. При анализе POC или эксплойта, прежде чем создавать эксплойт для этой конкретной уязвимости, вам необходимо рассмотреть следующие два сценария: Выполнить шеллкод\ Изменить адрес токена, используя примитивы чтения и записи. На основе более ранних уязвимостей CVE-2017-0263 и CVE-2016-0167, связанных с выполнением операций шеллкода. Примечания. Этот подход не рекомендуется из-за проблем с обеспечением поведения шелл-кода и механизмов безопасности (таких как SMEP) в более поздних версиях Windows. За последние несколько лет общедоступные POC продемонстрировали превосходство использования примитивов чтения и записи для изменения адресов токенов. Хотя этот тип уязвимости демонстрирует постоянство и универсальность с точки зрения структуры памяти рабочего стола, а также примитивов чтения и записи в куче рабочего стола, здесь также возникают значительные проблемы. Как контролировать значение cbwndextra при повторном использовании памяти UAF (использовать после освобождения)? Ответ: Автор рекомендует разделить весь эксплойт на две разные задачи: 1. Использование уязвимости UAF для контроля значения cbwndextra 2. Установление стабильного метода чтения и записи примитивов после получения контроля над значением cbwndextra;

Когда злоумышленник активирует эту уязвимость, система может выйти из строя. Это связано с тем, что метод запуска POC исключает все другие корреляции повторно используемых уязвимостей в системе. Система может неправильно использовать данные объекта окна из памяти, которую мы контролируем только в функциях MNGetPopupFromMenu() и xxxMNUpdateShownMenu() xxxEnableMenuItem. Чтобы занять освобожденный объект меню во время срабатывания уязвимости, можно использовать объект имени окна в классе окна WNDClass. Во время этого процесса происходит первая запись данных, когда мы определяем подходящее место в построенной структуре адреса. Это расположение позволяет нам записывать произвольные данные, даже один байт (можно записать старшие биты cbwndextra).

В функции xxxRedrawWindow мы определили два альтернативных способа обработки операций с соседними данными в памяти. Давайте рассмотрим эти методы более подробно: Метод с использованием GreCreateRectRgnIndirect / Метод, основанный на операции бита флага AND 2. Один из вариантов — использовать GreCreateRectRgnIndirect, но это сопряжено с двумя проблемами. Во-первых, управление первыми 8 битами cbwndextra оказалось трудным, поскольку оно лишь на короткое время становится равным 1 при определенных ограниченных условиях. Во-вторых, при использовании этого подхода другие относительные смещения cbwndextra будут указывать на последние 8 бит предыдущего объекта (независимо от типа объекта). Последние 8 битов обычно представляют собой байты безопасности в конце связанного списка кучи, и ими нелегко манипулировать. Учитывая трудности, связанные с первым подходом, мы выбрали альтернативный подход, который предполагает использование операции AND 2 для манипулирования битами флага. Однако управление байтом безопасности в конце связанного списка кучи остается проблемой. Чтобы преодолеть это препятствие, мы изменили нашу стратегию. Вместо записи в cb-extra объекта окна мы направляем операцию записи в cb-extra HWNDClass. Последний cb-extra имеет меньшее смещение, чем первый cb-extra, что позволяет нам манипулировать данными памяти предыдущего объекта в качестве параметра для проверки флага в функции xxxRedrawWindow (рис. 10).

Рисунок 10

Повышение привилегий ретрансляции 0X04NTLM (доменная среда)

Для повышения привилегий при входе в доменную среду мы можем использовать этот метод: Повышение привилегий ретрансляции NTLM (ссылка). В ретрансляторе NTLM злоумышленнику необходимо воспроизвести перехваченный хеш Net-NTLM для атаки, чтобы получить контроль над другими машинами. Для компьютеров рабочей группы пароли двух компьютеров должны быть одинаковыми для успеха, но для пользователей домена обманутый пользователь (пользователь, инициировавший запрос) должен быть пользователем в группе администраторов домена. После успешной ретрансляции NTLM. , Разрешения принадлежат обманутому пользователю. Чтобы успешное воспроизведение Net-NTLMhash, первое, что нужно сделать, — это получить этот Net-NTLMhash. Поскольку SMB, HTTP, LDAP, MSSQL и другие протоколы могут передавать три типа сообщений аутентификации NTLM, если вы используете SMB, HTTP, Программы, использующие LDAP, MSSQL и другие протоколы для аутентификации NTLM, могут попытаться отправить Net-NTLMhash злоумышленнику, чтобы злоумышленник мог перехватить Net-NTLMhash пользователя, а значит, мы можем осуществлять атаки через эти протоколы.

Рисунок 10один

Процесс сертификации NTLMиз (например, Рисунок 10-1):

1. Когда клиенту необходим доступ к серверу,клиент Вам необходимо ввести имя пользователя и пароль сервера для проверки,И клиент будет кэшировать значение NTLM-Hash сервера. После этого клиент начинает отправлять TYPE 1 Negotiate Сообщение для обращения на сервер.
2. Сервер получил клиент, отправленный из TYPE 1 Сообщение для После обработки он извлечет контент, который может принять, и передаст его в NTLM. SSP, получить ТИП 2 сообщения с вызовом, это TYPE 2Сообщение содержит 16-битное случайное значение, сгенерированное сервером и называемое Испытание. Сервер сохраняет копию этого задания и устанавливает ТИП 2 сообщения отправлены обратно клиенту
3. клиент Получено с сервераизTYPE 2 После сообщения прочитайте значение запроса, зашифруйте его с помощью NTLM-хэша пароля кэшированного сервера и объедините его с именем пользователя, запросом и т. д., чтобы получить Net-NTLMHash. и наконец Net-NTLMHash инкапсулированный в TYPE 3 Сообщение NTLM_AUTH отправлено на сервер
4. Сервер получает сообщение, отправленное клиентом TYPE 3 После получения сообщения выньте Сеть Значение NTLM-хэша и отправьте запрос на проверку контроллеру домена для клиентизации. В состав запроса входит: имя пользователя, оригинальное имя. Challenge и Зашифрованный вызов (т. е. Net NTLM-Hash)
5. DC получает хэш-значение пароля учетной записи на основе имени пользователя. NTLM-хеш со значением хеш-пароля NTLM-Hash Зашифруйте исходное задание по получению сети. NTLM-Hash。Если после шифрованияизChallengeи Сервер отправленизодин致,Это означает, что у пользователя правильный пароль.,Проверка пройдена,В противном случае проверка не удастся. DC отправляет результаты проверки на сервер

Во время аутентификации NTLM клиент может подтвердить свою личность серверу, зашифровав определенную информацию, предоставленную сервером, с помощью его пароля. Таким образом, все, что нужно сделать злоумышленнику, — это позволить клиенту выполнять свою работу и передавать сообщения от клиента к серверу и ответы от сервера к клиенту. Все сообщения, которые клиент хочет отправить на сервер, получит злоумышленник, а затем он отправит сообщения обратно на реальный сервер, и все сообщения, которые сервер хочет отправить клиенту, злоумышленник также получит. , и он будет отправлять их по мере пересылки клиенту. Фактически, с точки зрения клиента, между ним и злоумышленником происходит NTLM-аутентификация со всеми необходимыми условиями. Клиент отправляет запрос на согласование в своем первом сообщении, на который злоумышленник отвечает вызовом. После получения этого запроса клиент формирует свой ответ, используя свой секрет, и, наконец, отправляет окончательное сообщение аутентификации, содержащее зашифрованный запрос. Но злоумышленник ничего не может сделать с этим обменом. С точки зрения сервера злоумышленник является таким же клиентом, как и любой другой. Он отправляет первое сообщение с запросом аутентификации, и сервер отвечает запросом. Когда злоумышленник отправляет тот же запрос реальному клиенту, реальный клиент шифрует запрос своим секретом* и отвечает действительным. Таким образом, злоумышленник может отправить этот действительный ответ на сервер. С точки зрения сервера злоумышленник аутентифицировал себя, используя секрет жертвы, но он прозрачен для сервера. Он не знает, что злоумышленник воспроизводит свое сообщение клиенту, чтобы заставить клиента дать ему правильный ответ. В конце этих обменов злоумышленник проходит аутентификацию на сервере, используя учетные данные клиента.

Я рекомендую вам прочитать статью «Gone to the Dogs», в которой описывается метод получения примитивов аутентификации NetNTLM для учетной записи компьютера через HTTP в качестве непривилегированного пользователя путем использования функциональности специального экрана блокировки Windows. Для успешного использования этой уязвимости необходимы следующие предварительные условия: 1. Контроллер домена под управлением операционной системы Windows Server 2012 или более поздней версии. 2. Злоумышленник должен иметь доступ к объекту учетной записи пользователя или компьютера с установленным именем субъекта-службы или возможностью; для добавления новых компьютеров в домен; 3. Контроллер домена не должен быть настроен на принудительное подписание LDAP и привязку канала LDAP (настройки по умолчанию). 4. На компьютере-жертве должна быть установлена ​​и запущена служба «веб-клиент» (Windows 10); (установка по умолчанию); 5. Пользователям должно быть разрешено настраивать экран блокировки Windows (разрешения по умолчанию). Это содержимое заслуживает нашего тщательного анализа.

0X05Протокол Kerberos (доменная среда)

Кроме того, повышение привилегий при входе в среду домена может также привести к попытке ограниченного делегирования ресурсов или других атак на основе Kerberos. Так что же такое ограниченное делегирование на основе ресурсов? Ответ: RBAC — это модель управления доступом, которая контролирует доступ пользователей к ресурсам путем назначения пользователям разрешений. Ресурсом может быть объект любого типа, например файл, таблица базы данных или приложение. На многих предприятиях существует учетная запись специально для добавления машин в домен. Если мы получим права пользователя в группе «Операторы учетных записей», мы сможем получить системные права всех машин, кроме контроллера домена. Злоумышленник может запросить mS-DS-CreatorSID компьютера в домене. Это значение представляет пользователя, который добавил компьютер в домен. У него есть разрешение на изменение msDS-AllowedToActOnBehalfOfOtherIdentity. Если мы сможем получить учетные данные этого пользователя, мы можем контролировать все компьютеры, добавленные в домен этим пользователем.

Добавьте учетную запись компьютера, измените значение msDS-AllowedToActOnBehalfOfOtherIdentity на SID учетной записи компьютера, а затем притворитесь администратором учетной записи компьютера, чтобы подать заявку на получение билета для доступа к учетной записи компьютера (аналогично серебряному билету), поскольку учетная запись компьютера не настроена с делегированием привязки. Поэтому этот билет нельзя переслать, но при ограниченном делегировании на основе ресурсов не имеет значения, можно ли пересылать билет или нет. s4u2proxy не имеет никакого эффекта. Наконец, используйте этот билет, чтобы подать заявку на доступ к машине с измененным атрибутом msDSAllowedToActOnBehalfOfOtherIdentity.

Рисунок 10два

Оператор указал IP-адрес (192.168.184.144) вместо полного имени узла, указанного в имени субъекта службы, связанном с созданным билетом TGS (DESKTOP-KOERA35.CONTOSO.LOCAL).

Рисунок 10 три (Источник изображения преторианца)

Оператор может попытаться использовать Rubeus Создать новый маяк с хоста,для импорта изTGSбилета, полученного при выполнении S4U, в текущий сеанс входа в систему. Хотя этот метод существует и работает против других хостов,Но при попытке выполнить маяк с помощью WMI с того же хоста,Похоже, что «Полный вход в сеть» не будет выполнен. Напротив,Буду использовать связанные с процессомизтокен безопасности。Результат показан ниже。хотя“администратор”пользовательизTGSТокен связан с сеансом входа в систему.,Но вспомогательный маяк генерируется от имени пользователя JSMITH. Чтобы не столкнуться с этой проблемой,Мы должны использовать SOCKS для проксирования Impacket на хост, чтобы выполнить полный вход в сеть.

Рисунок 10 четыре (исходное изображение преторианца)

0X06 Метод защиты

Исправить проблемы с настройкой каталога системного пути относительно легко, поскольку вам нужно только изменить разрешения каталога, доступного для записи. Если установщик вашего приложения создает уязвимость пути записи путем изменения системных путей, рассмотрите возможность отправки отчета в Enterprise SRC.

1. Ограничить запись в каталоги с ограниченным доступом. Разрешения: Обеспечить, чтобы только авторизованные пользователи могли писать в каталоги с ограниченным доступом.
2. Веб-приложения или другие файлы, чтобы гарантировать, что они не будут записываться в каталоги с ограниченным доступом.
3. Используйте методы безопасного кодирования. Следуйте методам безопасного кодирования, чтобы избежать неправильной настройки приложений.
4. Используйте обнаружение вторженийсистема (IDS): развертывание IDS для обнаружения подозрительной активности, например попыток записи в каталоги с ограниченным доступом
5. Регулярно устанавливайте обновления: своевременно устанавливайте исправления безопасности.,Исправить известные лазейки

Также относительно легко устранить атаки с тестовой загрузкой DLL и атаки на повышение привилегий Win32k. Предприятиям необходимо усилить мониторинг и обновление оборудования безопасности. Благодаря диверсифицированным методам перехвата и внутреннему обучению внутри предприятия можно значительно снизить угрозы безопасности предприятия.

Используйте цифровые подписи: подписывайте законные файлы DLL, чтобы злоумышленники не могли использовать неподписанные вредоносные библиотеки DLL. Проверка целостности DLL: проверьте хэши или подписи файлов DLL, чтобы убедиться, что они не были подделаны. Проверка подписи кода: убедитесь, что загруженная DLL подписана доверенным органом. Система обнаружения/предотвращения вторжений в сеть (NIDS/NIPS): обнаруживает и блокирует вредоносные библиотеки DLL в сетевом трафике. Используйте изолированную программную среду: изолируйте конфиденциальные приложения в изолированной программной среде, чтобы ограничить доступ злоумышленников к системным ресурсам. Развертывание решений для защиты от вредоносных программ: обнаружение и блокирование вредоносных программ, использующих уязвимости Win32k. Используйте виртуализацию: виртуализируйте приложения и службы, чтобы изолировать их от потенциальных атак. Внедрить сегментацию сети: разделить сеть на отдельные зоны, чтобы ограничить горизонтальное перемещение злоумышленников по системе.

Что касается угрозы повышения привилегий в доменной среде, автор считает, что улучшение планирования безопасности предприятия и реализация стратегий настройки безопасности предприятия являются необходимыми шагами. Мы знаем, что ограниченное делегирование на основе ресурсов (RBCD) — это механизм делегирования, который позволяет пользователю или приложению получать доступ к определенным частям определенного ресурса или управлять им без предоставления полного контроля над всем ресурсом. Это помогает снизить риск атак с целью повышения привилегий, поскольку даже если злоумышленник получит доступ к ограниченному ресурсу, он или она не сможет получить доступ или изменить другие части ресурса. Меры защиты от атак с ограниченным делегированием ресурсов включают в себя:

Соблюдайте принцип минимальных привилегий: предоставляйте пользователям и приложениям только минимальные разрешения, необходимые им для выполнения своих задач, включая доступ к ресурсам. Используйте списки контроля доступа (ACL): Конфигурация ACL чтобы указать, какие пользователи и приложения могут получить доступ к каким частям ресурса Включить ведение журнала аудита: регистрируйте попытки доступа и изменения к ограниченным ресурсам для обнаружения подозрительной активности. использоватьБезопасное программированиеупражняться：Следуйте рекомендациям по безопасному кодированию,Например, проверка ввода и проверка границ.,Чтобы предотвратить переполнение буфера, целочисленное переполнение и т. д. лазейки

0X07 Заключение

С точки зрения технологии безопасности,Автор считает, что самый идеальный способ повышения локальных привилегий в Windows — это настройка пути к каталогу + боковая загрузка DLL. существуют во многих корпоративных средах,Автор установил, что вход в корпоративную среду через менеджмент,Веб-сервисы часто являются хорошим прорывом,пара средств безопасностиwebСлужитьиз Доступ не требуетсяМногофакторная аутентификация,Сотрудники предприятия обычно имеют доступ к веб-сайту.,и использование часто охватывает несколько отделов,На хостах веб-сервисов обычно установлено большое количество приложений.,Автор обнаружил, что на этих хостах существуют некоторые проблемы с настройкой каталога путей изсистемы. Потому что после успешного управления,Разрешения в целом не высокие,В настоящее время хорошим решением является проблема с настройкой каталога системного пути + загрузка стороны DLL.

Закрепившись в интрасети предприятия, выделив внутреннюю среду предприятия (рабочая группа\среда домена), после перемещения в горизонтальном направлении, используйте соответствующие методы атаки: повышение привилегий Win32k (рабочая группа) и повышение привилегий ретрансляции NTLM\протокол Kerberos (среда домена) для атаки. . Чтобы избежать обнаружения корпоративным SOC со зрелыми возможностями обнаружения и реагирования. В аналогичной среде необоснованное использование методов повышения привилегий и методов горизонтального перемещения будет быстро обнаружено корпоративным SOC и исключено, что приведет к провалу атаки.

Наконец, я хотел бы поблагодарить мастера Наньчэна за вдохновение для его статьи. Как безопасная соленая рыба, я надеюсь, что каждый сможет раскритиковать приведенную выше статью автора и внести исправления в область комментариев. Автор сохранит нормальный разум. Ведь в поднятии прав задействовано слишком много точек знаний, и у автора неизбежно будут упущения и недостатки. Можно сказать, что уровень злоумышленника тесно связан с его знаниями и способностями. Ни повышение привилегий Win32k, ни протокол Kerberos сейчас я не могу полностью понять. Поэтому автор смиренно принимает совпадения и наслаждается процессом обучения.

Справочная статья:

https://www.numencyber.com/cve-2023-29336-win32k-analysis/ https://github.com/0x5bfa/NT5.1/blob/1b390dddff9fe017e9c11a7845c67a887c3483dc/Source/XPSP1/NT/windows/core/ntuser/kernel/mnsys.c#L511 https://github.com/KaLendsi/CVE-2022-21882/blob/main/ExploitTest.cpp https://www.real-sec.com/2022/01/technical-analysis-of-cve-2021-1732/ https://techcommunity.microsoft.com/t5/core-infrastruct-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536 https://www.freebuf.com/articles/system/338877.html https://eladshamir.com/2019/08/08/Lock-Screen-LPE.html https://petri.com/understanding-kerberos-delegation-in-windows-server-active-directory https://support.microsoft.com/en-us/topic/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows-ef185fb8-00f7-167d-744c-f299a66fc00a