TL;DR : в этом сообщении блога описываются детали и методология нашего исследования, посвященного технологии установки установщика Windows (MSI). Если вас интересует только сама уязвимость, то переходите прямо сюда - https://blog.doyensec.com/#msi-vuln
Введение
Недавно я решил исследовать один общий аспект многих популярных приложений Windows — их установочные пакеты MSI.
Не каждое приложение распространяется таким образом. Некоторые приложения реализуют собственные механизмы начальной загрузки, некоторые просто предназначены для размещения на диске. Однако в типичной корпоративной среде часто желательна некоторая форма контроля над установленными пакетами. Использование пакетов MSI упрощает процесс установки для любого количества систем, а также предоставляет дополнительные преимущества, такие как автоматическое восстановление, простое исправление и совместимость с GPO. Хорошим примером является Google Chrome, который обычно распространяется как отдельный исполняемый файл, но корпоративный пакет предлагается на выделенном сайте.
Еще одним интересным аспектом корпоративных сред является необходимость жесткого контроля над учетными записями сотрудников. В частности, в хорошо защищенной среде Windows правило минимальных привилегий гарантирует, что административные права не будут предоставлены, если для этого нет действительно веской причины. Это плохая новость для вредоносных программ или злоумышленников, которым было бы полезно иметь под рукой дополнительные привилегии.
В ходе своего исследования я хотел взглянуть на безопасность популярных MSI-пакетов и понять, могут ли они быть использованы злоумышленником в каких-либо злонамеренных целях и, в частности, для повышения локальных привилегий.
Типичная установка
Для пакета MSI очень часто требуются права администратора. В результате запуск вредоносного установщика — это просто конец игры. Я хотел взглянуть на законные, правильно подписанные пакеты MSI. Попросить кого-нибудь ввести пароль администратора, а затем каким-то образом открыть cmd с повышенными правами — это тоже вариант, который я решил не рассматривать в этом сообщении блога.
Давайте быстро посмотрим, как генерируются файлы установщика. Оказывается, есть несколько вариантов создания пакета MSI. Одними из самых популярных являются WiX Toolset, InstallShield и Advanced Installer . Первый бесплатный и с открытым исходным кодом, но требует, чтобы вы написали специальные XML-файлы. Два других предлагают различные наборы функций, богатый графический интерфейс и поддержку клиентов, но требуют дополнительной лицензии. В этих продуктах можно поискать общие уязвимости, однако очень сложно учесть все возможные вариации предлагаемых функций. С другой стороны, именно здесь могут возникнуть настоящие ошибки в процессе установки.
В процессе установки будут созданы новые файлы. Некоторые существующие файлы также могут быть переименованы или удалены. Права доступа к различным защищаемым объектам могут быть изменены. Интересен вопрос, что произойдет, если появятся неожиданные права доступа. Произойдет ли сбой установщика или он попытается отредактировать списки разрешений? Большинство установщиков также модифицируют ключи реестра Windows, бросают некоторые ярлыки здесь и там и, наконец, регистрируют определенные действия в журнале событий, базе данных или обычных файлах.
Список действий на самом деле не скрыт. Пакеты MSI могут реализовывать так называемые настраиваемые действия, которые реализованы в выделенной библиотеке DLL. Если это так, то очень разумно поискать интересные баги там.
Как только у нас есть готовый и установленный пакет установщика, мы часто можем наблюдать, как новая копия кэшируется в каталоге C:\Windows\Installers. Это скрытый системный каталог, в который непривилегированные пользователи не могут писать. Копии пакетов MSI переименовываются в случайные имена, соответствующие следующему регулярному выражению: ^[0-9a-z]{7}\.msi$. Имя будет уникальным для каждой машины и даже для каждой новой установки. Чтобы идентифицировать конкретный пакет, мы можем посмотреть свойства файла (но создатель MSI должен решить, какие свойства настроены), выполнить поиск в реестре Windows или запросить WMI:
Обращение к пакету через его GUID — наша самая безопасная возможность. Однако разные версии одного и того же продукта могут иметь разные идентификаторы.
Предполагая, что мы используем непривилегированную учетную запись пользователя, можем ли мы сделать что-нибудь интересное с этим знанием?
Процесс восстановления
Встроенный инструмент Windows, называемый msiexec.exe, находится в каталогах System32 и SysWOW64. Он используется для управления пакетами MSI. Инструмент является основным компонентом Windows с долгой историей уязвимостей. В качестве примечания, я также обнаружил одну такую проблему в прошлом ( CVE-2021-26415). Документированный список его параметров можно найти на странице MSDN, хотя также реализованы некоторые дополнительные недокументированные переключатели.
Флаги, на которые стоит обратить внимание:
/l*vx - регистрирует любые дополнительные детали и ищет интересные события
/qn- нужен чтобы скрыть любые взаимодействия с пользовательским интерфейсом. Это чрезвычайно полезно при попытке разработать автоматизированный эксплойт. С другой стороны, потенциальные ошибки приведут к появлению новых окон сообщений. Пока сообщение не будет принято, процесс не будет продолжаться и может быть заморожен в непредвиденном состоянии. Возможно, мы сможем изменить некоторые существующие файлы до того, как первоначальные права доступа будут восстановлены.
В разделе параметров восстановления перечислены флаги, которые мы могли бы использовать для запуска действий по восстановлению. Эти действия обеспечат удаление плохих файлов и переустановку хороших файлов. Определение «плохой» — это то, что мы контролируем, т. е. мы можем принудительно переустановить все файлы, все записи реестра или, скажем, только те, у которых неверная контрольная сумма.
/fp - Восстанавливает пакет, если файл отсутствует.
/fo - Восстанавливает пакет, если файл отсутствует или установлена более старая версия.
/fe - Восстанавливает пакет, если файл отсутствует или установлена равноценная или старая версия.
/fd - Восстанавливает пакет, если файл отсутствует или установлена другая версия.
/fc - Восстанавливает пакет, если файл отсутствует или контрольная сумма не соответствует рассчитанному значению.
/fa - Принудительно переустанавливает все файлы.
/fu - Восстанавливает все необходимые пользовательские записи реестра.
/fm - Восстанавливает все необходимые записи реестра для конкретного компьютера.
/fs - Восстанавливает все существующие ярлыки.
/fv - Запускается из исходного кода и повторно кэширует локальный пакет.
Для большинства msiexec действий потребуется повышение прав. Мы не можем устанавливать или удалять произвольные пакеты (если, конечно, система не настроена неправильно). Однако вариант ремонта может быть интересным исключением! Может быть, потому что не каждый пакет будет работать так, но найти такой несложно. Для них msiexec автоматически повышается уровень для выполнения необходимых действий в качестве пользователя СИСТЕМЫ. Интересно, что некоторые действия по-прежнему будут выполняться с использованием нашей непривилегированной учетной записи, что делает случай еще более примечательным.
Олицетворение нашей учетной записи произойдет по различным причинам безопасности. Однако только некоторые действия могут быть олицетворены. Если вы видите файл, переименованный пользователем SYSTEM, это всегда будет полностью привилегированное действие. С другой стороны, при анализе того, кто именно пишет в данный файл, нам нужно в первую очередь посмотреть, как был открыт дескриптор файла.
Мы можем использовать такие инструменты, как Process Monitor, для наблюдения за всеми этими событиями. Чтобы отфильтровать шум, я бы рекомендовал использовать настройки, показанные ниже. Пропустить что-то интересное, например, действия дочерних процессов, можно, но вникать в каждое событие сразу нереально. Кроме того, я намеренно отключил отслеживание активности в реестре, но иногда стоит снова включить его, чтобы проверить, не контролируются ли определенные действия редактируемыми разделами реестра.
Еще один прием, который я бы порекомендовал, состоит в том, чтобы выделить различие между олицетворенными и неимперсонализированными операциями. Я предпочитаю выделять все, что явно не олицетворяется, но вы можете предпочесть изменить логику.
Затем, чтобы начать анализ событий вышеупомянутого установщика Google Chrome, можно выполнить следующую команду:
Поток событий должен быть зафиксирован ProcMon, но чтобы искать проблемы, нам нужно понять, что можно считать проблемой. Короче говоря, интересно любое действие над защищаемым объектом, который мы можем как-то модифицировать. SYSTEM записывает файл, которым мы управляем? Это наша цель.
Как правило, мы не можем напрямую контролировать затронутый путь. Однако мы можем заменить исходный файл символической ссылкой. Обычные символические ссылки, скорее всего, недоступны для непривилегированных пользователей, но мы можем использовать некоторые приемы и инструменты, чтобы заново изобрести функциональность в Windows.
Примитивы Windows EoP
Хотя мы не пытаемся вскрыть каждую обнаруженную уязвимость, интересно рассказать читателям о том, что было бы возможно с учетом некоторых примитивов повышения привилегий.
С помощью уязвимости создания произвольного файла мы можем атаковать систему, создав DLL, которую загрузит один из системных процессов. Немного сложнее, но не невозможно найти процесс Windows, который загружает нашу установленную DLL без перезагрузки всей системы.
Имея уязвимость создания произвольного файла, но не имея контроля над содержимым , наши шансы взломать оболочку резко уменьшаются. Однако мы все еще можем сделать Windows неработоспособной.
С произвольной уязвимостью удаления файла мы можем как минимум сломать операционную систему. Однако часто мы также можем превратить это в произвольное удаление папки и использовать сложный метод, обнаруженный Абдельхамидом Насери, для фактического открытия оболочки .
Список возможных примитивов длинный и увлекательный. Тем не менее один примитив EoP следует рассматривать как серьезную проблему безопасности.
Одна уязвимость, чтобы победить их всех (CVE-2023-21800)
Я наблюдал такое же интересное поведение во многих протестированных пакетах MSI. Пакеты были созданы разными создателями MSI с использованием разных типов ресурсов и в основном не имели ничего общего. Тем не менее, все они следовали одной и той же схеме. А именно, переменные среды, установленные непривилегированным пользователем, также использовались в контексте пользователя SYSTEM, вызванного операцией восстановления.
Хотя я изначально думал, что приложения неправильно доверяют некоторым переменным среды, оказалось, что за небезопасные действия отвечает механизм отката установщика Windows.
7-zip
7-Zip предоставляет специальные установщики Windows, которые публикуются на странице проекта. Был протестирован следующий файл 7z2201-x64.ms
Чтобы лучше понять проблему, мы можем изучить исходный код приложения. Установщик, определенный в DOC/7zip.wxs, ссылается на идентификатор ProgramMenuFolder.
Позднее ProgramMenuFolder используется для хранения некоторых компонентов, таких как ярлык файла 7-zip.chm.
Как указано на странице MSDN :
Установщик задает для свойства ProgramMenuFolder полный путь к папке меню программы для текущего пользователя. Если существует профиль «Все пользователи» и установлено свойство ALLUSERS, то это свойство устанавливается для папки в профиле «Все пользователи».
Другими словами, свойство будет указывать либо на каталог, контролируемый текущим пользователем (in, %APPDATA%как в предыдущем примере), либо на каталог, связанный с профилем «Все пользователи».
В то время как первая конфигурация не требует дополнительных пояснений, вторая конфигурация сложна. Путь C:\ProgramData\Microsoft\Windows\Start Menu\Programs обычно используется, пока C:\ProgramDataон доступен для записи даже непривилегированным пользователям. Путь C:\ProgramData\Microsoft правильно заблокирован. Это оставляет нас с безопасным значением по умолчанию.
Однако пользователь, запускающий процесс восстановления, может намеренно изменить (т. е. отравить) PROGRAMDATA переменную среды и, таким образом, перенаправить профиль «Все пользователи» в произвольное место, доступное для записи пользователю. setx Для этого можно использовать команду setx. Он изменяет переменные, связанные с текущим пользователем, но важно подчеркнуть, что это влияет только на будущие сеансы cmd.exe. Для наследования новых настроек следует запустить совершенно новый экземпляр.
Вместо того, чтобы размещать легальные файлы, символическая ссылка на произвольный файл может быть размещена в %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\7-zip\ каталоге как один из ожидаемых файлов. В результате операция будет такой:
- Удалить произвольный файл (используя системные привилегии)
- Попытаться восстановить исходный файл (используя непривилегированную учетную запись пользователя)
Второе действие завершится ошибкой, что приведет к примитиву произвольного удаления файла. Это можно наблюдать на следующем снимке, предполагая, что мы нацелены на ранее созданный C:\Windows\System32\__doyensec.txt файл. Мы намеренно создали символическую ссылку на целевой файл по пути C:\FakeProgramData\Microsoft\Windows\Start Menu\Programs\7-zip\7-Zip Help.lnk.
Во-первых, мы можем видеть действия, приводящие к статусу REPARSE. Кратковременно обрабатывается файл (точнее его атрибуты), и SetRenameInformationFile. Часть переименования немного вводит в заблуждение. На самом деле происходит то, что файл перемещается в другое место. Вот как установщик Windows создает инструкции по откату на случай, если что-то пойдет не так. Как указывалось ранее, SetRenameInformationFile не работает на уровне дескриптора файла и не может олицетворяться. Это действие выполняется с полными привилегиями SYSTEM.
Позже мы можем обнаружить попытки восстановить исходный файл, но с использованием олицетворенного токена. Эти действия приводят к ошибкам ACCESS DENIED, поэтому целевой файл остается удаленным.
Такая же последовательность наблюдалась и во многих других инсталляторах. Например, я работал с PuTTY над возможным обходным путем, который был представлен в версии 0.78. В этой версии восстановление с повышенными правами разрешено только в том случае, если предоставлены учетные данные администратора. Однако это функционально не равнозначно и привело к некоторым другим проблемам. Версия 0.79 должна восстановить старую конфигурацию WiX.
Защита перенаправления
О проблеме было сообщено непосредственно в Microsoft со всей вышеуказанной информацией и специальным эксплойтом. Microsoft присвоила ему идентификатор CVE-2023-21800 .
Его можно было воспроизвести в последних версиях Windows 10 и Windows 11. Однако он не соответствовал критериям вознаграждения, поскольку атака уже была защищена в Windows 11 Developer Preview. То же средство защиты было включено в обновлении 2022-02-14.
В октябре 2022 года Microsoft выпустила новую функцию под названием Redirection Guard в Windows 10 и Windows 11. В обновлении представлен новый тип защиты под названием ProcessRedirectionTrustPolicy и соответствующая структура PROCESS_MITIGATION_REDIRECTION_TRUST_POLICY. Если для данного процесса включена защита, все обработанные соединения проверяются дополнительно. Проверка сначала проверяет, было ли соединение файловой системы создано пользователями, не являющимися администраторами, и, если да, не запрещает ли политика следование за ними. Если операция предотвращена, 0xC00004BC возвращается ошибка. Соединения, созданные пользователями-администраторами, явно разрешены как имеющие метку более высокого уровня доверия.
В начальном раунде Redirection Guard был включен для службы печати. Обновление 2022-02-14 включило такое же зашиту в msiexec процессе.
Это можно наблюдать на следующем захвате ProcMon:
msiexec - одно из немногих приложений, в которых это средство защиты применяется по умолчанию. Чтобы проверить это самостоятельно, используйте следующий не очень хороший код:
Redirection Guard должен предотвращать целый класс перекрестных атак и может значительно усложнить локальные атаки с повышением привилегий. Хотя он решает ранее упомянутую проблему, он также устраняет другие типы ошибок установщика, например, когда привилегированный установщик перемещает файлы из каталогов, контролируемых пользователем.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://blog.doyensec.com/2023/03/21/windows-installer.html
Введение
Недавно я решил исследовать один общий аспект многих популярных приложений Windows — их установочные пакеты MSI.
Не каждое приложение распространяется таким образом. Некоторые приложения реализуют собственные механизмы начальной загрузки, некоторые просто предназначены для размещения на диске. Однако в типичной корпоративной среде часто желательна некоторая форма контроля над установленными пакетами. Использование пакетов MSI упрощает процесс установки для любого количества систем, а также предоставляет дополнительные преимущества, такие как автоматическое восстановление, простое исправление и совместимость с GPO. Хорошим примером является Google Chrome, который обычно распространяется как отдельный исполняемый файл, но корпоративный пакет предлагается на выделенном сайте.
Еще одним интересным аспектом корпоративных сред является необходимость жесткого контроля над учетными записями сотрудников. В частности, в хорошо защищенной среде Windows правило минимальных привилегий гарантирует, что административные права не будут предоставлены, если для этого нет действительно веской причины. Это плохая новость для вредоносных программ или злоумышленников, которым было бы полезно иметь под рукой дополнительные привилегии.
В ходе своего исследования я хотел взглянуть на безопасность популярных MSI-пакетов и понять, могут ли они быть использованы злоумышленником в каких-либо злонамеренных целях и, в частности, для повышения локальных привилегий.
Типичная установка
Для пакета MSI очень часто требуются права администратора. В результате запуск вредоносного установщика — это просто конец игры. Я хотел взглянуть на законные, правильно подписанные пакеты MSI. Попросить кого-нибудь ввести пароль администратора, а затем каким-то образом открыть cmd с повышенными правами — это тоже вариант, который я решил не рассматривать в этом сообщении блога.
Давайте быстро посмотрим, как генерируются файлы установщика. Оказывается, есть несколько вариантов создания пакета MSI. Одними из самых популярных являются WiX Toolset, InstallShield и Advanced Installer . Первый бесплатный и с открытым исходным кодом, но требует, чтобы вы написали специальные XML-файлы. Два других предлагают различные наборы функций, богатый графический интерфейс и поддержку клиентов, но требуют дополнительной лицензии. В этих продуктах можно поискать общие уязвимости, однако очень сложно учесть все возможные вариации предлагаемых функций. С другой стороны, именно здесь могут возникнуть настоящие ошибки в процессе установки.
В процессе установки будут созданы новые файлы. Некоторые существующие файлы также могут быть переименованы или удалены. Права доступа к различным защищаемым объектам могут быть изменены. Интересен вопрос, что произойдет, если появятся неожиданные права доступа. Произойдет ли сбой установщика или он попытается отредактировать списки разрешений? Большинство установщиков также модифицируют ключи реестра Windows, бросают некоторые ярлыки здесь и там и, наконец, регистрируют определенные действия в журнале событий, базе данных или обычных файлах.
Список действий на самом деле не скрыт. Пакеты MSI могут реализовывать так называемые настраиваемые действия, которые реализованы в выделенной библиотеке DLL. Если это так, то очень разумно поискать интересные баги там.
Как только у нас есть готовый и установленный пакет установщика, мы часто можем наблюдать, как новая копия кэшируется в каталоге C:\Windows\Installers. Это скрытый системный каталог, в который непривилегированные пользователи не могут писать. Копии пакетов MSI переименовываются в случайные имена, соответствующие следующему регулярному выражению: ^[0-9a-z]{7}\.msi$. Имя будет уникальным для каждой машины и даже для каждой новой установки. Чтобы идентифицировать конкретный пакет, мы можем посмотреть свойства файла (но создатель MSI должен решить, какие свойства настроены), выполнить поиск в реестре Windows или запросить WMI:
Обращение к пакету через его GUID — наша самая безопасная возможность. Однако разные версии одного и того же продукта могут иметь разные идентификаторы.
Предполагая, что мы используем непривилегированную учетную запись пользователя, можем ли мы сделать что-нибудь интересное с этим знанием?
Процесс восстановления
Встроенный инструмент Windows, называемый msiexec.exe, находится в каталогах System32 и SysWOW64. Он используется для управления пакетами MSI. Инструмент является основным компонентом Windows с долгой историей уязвимостей. В качестве примечания, я также обнаружил одну такую проблему в прошлом ( CVE-2021-26415). Документированный список его параметров можно найти на странице MSDN, хотя также реализованы некоторые дополнительные недокументированные переключатели.
Флаги, на которые стоит обратить внимание:
/l*vx - регистрирует любые дополнительные детали и ищет интересные события
/qn- нужен чтобы скрыть любые взаимодействия с пользовательским интерфейсом. Это чрезвычайно полезно при попытке разработать автоматизированный эксплойт. С другой стороны, потенциальные ошибки приведут к появлению новых окон сообщений. Пока сообщение не будет принято, процесс не будет продолжаться и может быть заморожен в непредвиденном состоянии. Возможно, мы сможем изменить некоторые существующие файлы до того, как первоначальные права доступа будут восстановлены.
В разделе параметров восстановления перечислены флаги, которые мы могли бы использовать для запуска действий по восстановлению. Эти действия обеспечат удаление плохих файлов и переустановку хороших файлов. Определение «плохой» — это то, что мы контролируем, т. е. мы можем принудительно переустановить все файлы, все записи реестра или, скажем, только те, у которых неверная контрольная сумма.
/fp - Восстанавливает пакет, если файл отсутствует.
/fo - Восстанавливает пакет, если файл отсутствует или установлена более старая версия.
/fe - Восстанавливает пакет, если файл отсутствует или установлена равноценная или старая версия.
/fd - Восстанавливает пакет, если файл отсутствует или установлена другая версия.
/fc - Восстанавливает пакет, если файл отсутствует или контрольная сумма не соответствует рассчитанному значению.
/fa - Принудительно переустанавливает все файлы.
/fu - Восстанавливает все необходимые пользовательские записи реестра.
/fm - Восстанавливает все необходимые записи реестра для конкретного компьютера.
/fs - Восстанавливает все существующие ярлыки.
/fv - Запускается из исходного кода и повторно кэширует локальный пакет.
Для большинства msiexec действий потребуется повышение прав. Мы не можем устанавливать или удалять произвольные пакеты (если, конечно, система не настроена неправильно). Однако вариант ремонта может быть интересным исключением! Может быть, потому что не каждый пакет будет работать так, но найти такой несложно. Для них msiexec автоматически повышается уровень для выполнения необходимых действий в качестве пользователя СИСТЕМЫ. Интересно, что некоторые действия по-прежнему будут выполняться с использованием нашей непривилегированной учетной записи, что делает случай еще более примечательным.
Олицетворение нашей учетной записи произойдет по различным причинам безопасности. Однако только некоторые действия могут быть олицетворены. Если вы видите файл, переименованный пользователем SYSTEM, это всегда будет полностью привилегированное действие. С другой стороны, при анализе того, кто именно пишет в данный файл, нам нужно в первую очередь посмотреть, как был открыт дескриптор файла.
Мы можем использовать такие инструменты, как Process Monitor, для наблюдения за всеми этими событиями. Чтобы отфильтровать шум, я бы рекомендовал использовать настройки, показанные ниже. Пропустить что-то интересное, например, действия дочерних процессов, можно, но вникать в каждое событие сразу нереально. Кроме того, я намеренно отключил отслеживание активности в реестре, но иногда стоит снова включить его, чтобы проверить, не контролируются ли определенные действия редактируемыми разделами реестра.
Еще один прием, который я бы порекомендовал, состоит в том, чтобы выделить различие между олицетворенными и неимперсонализированными операциями. Я предпочитаю выделять все, что явно не олицетворяется, но вы можете предпочесть изменить логику.
Затем, чтобы начать анализ событий вышеупомянутого установщика Google Chrome, можно выполнить следующую команду:
Поток событий должен быть зафиксирован ProcMon, но чтобы искать проблемы, нам нужно понять, что можно считать проблемой. Короче говоря, интересно любое действие над защищаемым объектом, который мы можем как-то модифицировать. SYSTEM записывает файл, которым мы управляем? Это наша цель.
Как правило, мы не можем напрямую контролировать затронутый путь. Однако мы можем заменить исходный файл символической ссылкой. Обычные символические ссылки, скорее всего, недоступны для непривилегированных пользователей, но мы можем использовать некоторые приемы и инструменты, чтобы заново изобрести функциональность в Windows.
Примитивы Windows EoP
Хотя мы не пытаемся вскрыть каждую обнаруженную уязвимость, интересно рассказать читателям о том, что было бы возможно с учетом некоторых примитивов повышения привилегий.
С помощью уязвимости создания произвольного файла мы можем атаковать систему, создав DLL, которую загрузит один из системных процессов. Немного сложнее, но не невозможно найти процесс Windows, который загружает нашу установленную DLL без перезагрузки всей системы.
Имея уязвимость создания произвольного файла, но не имея контроля над содержимым , наши шансы взломать оболочку резко уменьшаются. Однако мы все еще можем сделать Windows неработоспособной.
С произвольной уязвимостью удаления файла мы можем как минимум сломать операционную систему. Однако часто мы также можем превратить это в произвольное удаление папки и использовать сложный метод, обнаруженный Абдельхамидом Насери, для фактического открытия оболочки .
Список возможных примитивов длинный и увлекательный. Тем не менее один примитив EoP следует рассматривать как серьезную проблему безопасности.
Одна уязвимость, чтобы победить их всех (CVE-2023-21800)
Я наблюдал такое же интересное поведение во многих протестированных пакетах MSI. Пакеты были созданы разными создателями MSI с использованием разных типов ресурсов и в основном не имели ничего общего. Тем не менее, все они следовали одной и той же схеме. А именно, переменные среды, установленные непривилегированным пользователем, также использовались в контексте пользователя SYSTEM, вызванного операцией восстановления.
Хотя я изначально думал, что приложения неправильно доверяют некоторым переменным среды, оказалось, что за небезопасные действия отвечает механизм отката установщика Windows.
7-zip
7-Zip предоставляет специальные установщики Windows, которые публикуются на странице проекта. Был протестирован следующий файл 7z2201-x64.ms
Чтобы лучше понять проблему, мы можем изучить исходный код приложения. Установщик, определенный в DOC/7zip.wxs, ссылается на идентификатор ProgramMenuFolder.
Позднее ProgramMenuFolder используется для хранения некоторых компонентов, таких как ярлык файла 7-zip.chm.
Как указано на странице MSDN :
Установщик задает для свойства ProgramMenuFolder полный путь к папке меню программы для текущего пользователя. Если существует профиль «Все пользователи» и установлено свойство ALLUSERS, то это свойство устанавливается для папки в профиле «Все пользователи».
Другими словами, свойство будет указывать либо на каталог, контролируемый текущим пользователем (in, %APPDATA%как в предыдущем примере), либо на каталог, связанный с профилем «Все пользователи».
В то время как первая конфигурация не требует дополнительных пояснений, вторая конфигурация сложна. Путь C:\ProgramData\Microsoft\Windows\Start Menu\Programs обычно используется, пока C:\ProgramDataон доступен для записи даже непривилегированным пользователям. Путь C:\ProgramData\Microsoft правильно заблокирован. Это оставляет нас с безопасным значением по умолчанию.
Однако пользователь, запускающий процесс восстановления, может намеренно изменить (т. е. отравить) PROGRAMDATA переменную среды и, таким образом, перенаправить профиль «Все пользователи» в произвольное место, доступное для записи пользователю. setx Для этого можно использовать команду setx. Он изменяет переменные, связанные с текущим пользователем, но важно подчеркнуть, что это влияет только на будущие сеансы cmd.exe. Для наследования новых настроек следует запустить совершенно новый экземпляр.
Вместо того, чтобы размещать легальные файлы, символическая ссылка на произвольный файл может быть размещена в %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\7-zip\ каталоге как один из ожидаемых файлов. В результате операция будет такой:
- Удалить произвольный файл (используя системные привилегии)
- Попытаться восстановить исходный файл (используя непривилегированную учетную запись пользователя)
Второе действие завершится ошибкой, что приведет к примитиву произвольного удаления файла. Это можно наблюдать на следующем снимке, предполагая, что мы нацелены на ранее созданный C:\Windows\System32\__doyensec.txt файл. Мы намеренно создали символическую ссылку на целевой файл по пути C:\FakeProgramData\Microsoft\Windows\Start Menu\Programs\7-zip\7-Zip Help.lnk.
Во-первых, мы можем видеть действия, приводящие к статусу REPARSE. Кратковременно обрабатывается файл (точнее его атрибуты), и SetRenameInformationFile. Часть переименования немного вводит в заблуждение. На самом деле происходит то, что файл перемещается в другое место. Вот как установщик Windows создает инструкции по откату на случай, если что-то пойдет не так. Как указывалось ранее, SetRenameInformationFile не работает на уровне дескриптора файла и не может олицетворяться. Это действие выполняется с полными привилегиями SYSTEM.
Позже мы можем обнаружить попытки восстановить исходный файл, но с использованием олицетворенного токена. Эти действия приводят к ошибкам ACCESS DENIED, поэтому целевой файл остается удаленным.
Такая же последовательность наблюдалась и во многих других инсталляторах. Например, я работал с PuTTY над возможным обходным путем, который был представлен в версии 0.78. В этой версии восстановление с повышенными правами разрешено только в том случае, если предоставлены учетные данные администратора. Однако это функционально не равнозначно и привело к некоторым другим проблемам. Версия 0.79 должна восстановить старую конфигурацию WiX.
Защита перенаправления
О проблеме было сообщено непосредственно в Microsoft со всей вышеуказанной информацией и специальным эксплойтом. Microsoft присвоила ему идентификатор CVE-2023-21800 .
Его можно было воспроизвести в последних версиях Windows 10 и Windows 11. Однако он не соответствовал критериям вознаграждения, поскольку атака уже была защищена в Windows 11 Developer Preview. То же средство защиты было включено в обновлении 2022-02-14.
В октябре 2022 года Microsoft выпустила новую функцию под названием Redirection Guard в Windows 10 и Windows 11. В обновлении представлен новый тип защиты под названием ProcessRedirectionTrustPolicy и соответствующая структура PROCESS_MITIGATION_REDIRECTION_TRUST_POLICY. Если для данного процесса включена защита, все обработанные соединения проверяются дополнительно. Проверка сначала проверяет, было ли соединение файловой системы создано пользователями, не являющимися администраторами, и, если да, не запрещает ли политика следование за ними. Если операция предотвращена, 0xC00004BC возвращается ошибка. Соединения, созданные пользователями-администраторами, явно разрешены как имеющие метку более высокого уровня доверия.
В начальном раунде Redirection Guard был включен для службы печати. Обновление 2022-02-14 включило такое же зашиту в msiexec процессе.
Это можно наблюдать на следующем захвате ProcMon:
msiexec - одно из немногих приложений, в которых это средство защиты применяется по умолчанию. Чтобы проверить это самостоятельно, используйте следующий не очень хороший код:
C:
#include <windows.h>
#include <TlHelp32.h>
#include <cstdio>
#include <string>
#include <vector>
#include <memory>
using AutoHandle = std::unique_ptr<std::remove_pointer_t<HANDLE>, decltype(&CloseHandle)>;
using Proc = std::pair<std::wstring, AutoHandle>;
std::vector<Proc> getRunningProcesses() {
std::vector<Proc> processes;
std::unique_ptr<std::remove_pointer_t<HANDLE>, decltype(&CloseHandle)> snapshot(CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0), &CloseHandle);
PROCESSENTRY32 pe32;
pe32.dwSize = sizeof(pe32);
Process32First(snapshot.get(), &pe32);
do {
auto h = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, pe32.th32ProcessID);
if (h) {
processes.emplace_back(std::wstring(pe32.szExeFile), AutoHandle(h, &CloseHandle));
}
} while (Process32Next(snapshot.get(), &pe32));
return processes;
}
int main() {
auto runningProcesses = getRunningProcesses();
PROCESS_MITIGATION_REDIRECTION_TRUST_POLICY policy;
for (auto& process : runningProcesses) {
auto result = GetProcessMitigationPolicy(process.second.get(), ProcessRedirectionTrustPolicy, &policy, sizeof(policy));
if (result && (policy.AuditRedirectionTrust | policy.EnforceRedirectionTrust | policy.Flags)) {
printf("%ws:\n", process.first.c_str());
printf("\tAuditRedirectionTrust: % d\n\tEnforceRedirectionTrust : % d\n\tFlags : % d\n", policy.AuditRedirectionTrust, policy.EnforceRedirectionTrust, policy.Flags);
}
}
}Redirection Guard должен предотвращать целый класс перекрестных атак и может значительно усложнить локальные атаки с повышением привилегий. Хотя он решает ранее упомянутую проблему, он также устраняет другие типы ошибок установщика, например, когда привилегированный установщик перемещает файлы из каталогов, контролируемых пользователем.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://blog.doyensec.com/2023/03/21/windows-installer.html