Команда Google Project Zero известна тем, что обнаруживает уязвимости в программном обеспечении, разработанном как самой компанией, так и другими фирмами. Ее методология предполагает выявление недостатков в программном обеспечении и конфиденциальное сообщение о них поставщикам, давая им 90 дней на их устранение до публичного раскрытия. В зависимости от сложности требуемого исправления, компания иногда предоставляет дополнительные дни в виде льготного периода.
За последние несколько лет команда безопасности обнаружила и раскрыла множество дефектов безопасности, после того как соответствующие производители не смогли своевременно их устранить. К ним относятся драйверы GPU Adreno от Qualcomm, Windows от Microsoft, macOS от Apple и многое другое. Недавно также был представлен новый вариант Rowhammer, который может быть использован для изменения содержимого памяти новых чипов DRAM. После неудачного исправления Microsoft раскрыла ошибку Windows «низкой» степени серьезности, которая может привести к повышению привилегий.
О проблеме, о которой идет речь, сообщил Джеймс Форшоу из Google Project Zero. Полную информацию о проблеме можно посмотреть здесь, но, как обычно, она носит довольно технический характер. Суть проблемы связана с тем, что платформа фильтрации Windows Filtering Platform не проверяет корректность паролирования токенов при проверке фильтров, что может привести к атакам EoP.
По сути, когда создается IP-сокет, контекст безопасности текущего вызывающего абонента извлекается драйвером TCP/IP, который затем использует эту информацию для выполнения проверок брандмауэра. Поэтому всякий раз, когда на сокете выполняется какое-либо действие, драйвер TCP/IP посылает вызов драйверу NETIO, чтобы проверить, разрешено ли оно на основе конфигураций брандмауэра Windows Firewall и Base Filtering Engine. Одним словом, если эти правила каким-то образом обойдены вызывающей стороной, злоумышленник может выполнять сетевые операции, даже если брандмауэр не должен позволять ему это делать.
Форшоу смог обойти эти условия брандмауэра в Windows 10 20H2 из-за того, как операционная система устанавливает правила по умолчанию для AppContainers (AC), которые не позволяют им подключаться к сети, если не предоставлены определенные разрешения. По словам исследователя безопасности, существует множество проблем с тем, как проверяются правила брандмауэра.
После преобразования токена в определенную структуру проверка на уровне имперсонации не выполняется. Хотя это не является проблемой само по себе, может возникнуть потенциальная проблема, когда вторая проверка проверяет, был ли токен уже кэширован или нет. По сути, если процесс AppContainer способен украсть проверенный токен процесса, не являющегося AppContainer, он может обойти эту проверку, выдавая себя за другого, при этом брандмауэр не будет знать, что на самом деле это другой процесс, которому не разрешено обходить фильтры.
Форшоу описал и другие уязвимости в этом процессе, заявив, что если токен еще не кэширован, он вручную перечисляет идентификаторы безопасности (SID) для проверки сетевых возможностей и устанавливает определенные флаги, которые, вероятно, используются для обхода других проверок в брандмауэре. Важно отметить, что проверка на уровне имперсонации все еще не была произведена. Как описывает исследователь безопасности:
В этот момент сокет уже создан с сохраненной в нем информацией безопасности. Ничего не произойдет, пока операция, такая как вызов соединения, не задействует фильтрацию. Хотя отсутствие проверок на имперсональность является проблемой, это может не иметь значения, пока код, выполняющий проверки доступа, корректен. К сожалению, это не так. Проверки, похоже, находятся в NETIO!MatchValues, который проходит через правила фильтрации и применяет операции к сетевому соединению. Это может включать проверку SID из информации токена или вызов SeAccessCheckFromStateEx. При проверке только SID снова нет проверки уровня обезличивания, но, вероятно, она должна быть. Однако самой большой проблемой является вызов SeAccessCheckFromStateEx. Он принимает два маркера от вызывающей стороны, первичный маркер и маркер обезличивания. Поскольку код в TCPIP принимает только один маркер, MatchValues всегда передает этот маркер в качестве основного. Принцип работы основных API проверки доступа заключается в том, что проверка на обезличивание для SecurityImpersonation или выше выполняется только в том случае, если маркер обезличивания был передан в качестве маркера обезличивания. Если вы передаете токен обезличивания в качестве основного токена, код никогда не проверяет уровень и продолжает проверку доступа. Это означает, что вызывающая сторона может проходить проверку доступа так, как если бы она не находилась в AC, предполагая, что она передает токен, не являющийся AC.
Джеймс Фошоу также объяснил, что процессам AppContainer относительно легко получить токен не AppContainer и обойти проверки брандмауэра. Хотя большинство драйверов устройств ограничивают доступ к токенам AppContainer или идентификационного уровня, это не так, когда речь идет о драйвере вспомогательных функций Windows (AFD), который позволяет создавать сокеты для обоих этих типов. Форшоу утверждает, что использование этой возможности в своих интересах также является довольно тривиальным процессом.
Исследователь безопасности предложил блокировать создание сокетов для всех абонентов, выдающих себя за идентификационные маркеры, за исключением некоторых исключительных случаев, и предоставил доказательство концепции (PoC) кода, демонстрирующего эксплойт.
О проблеме было частным образом сообщено в Microsoft 24 марта, и компания подтвердила, что исправление было выложено в июньском обновлении Patch Tuesday, выпущенном 8 июня. Подробности уязвимости можно увидеть в CVE-2021-31970, где Microsoft признала Google Project Zero, подтвердив при этом, что это локальный вектор атаки на различные операционные системы, включая Windows 8.1, Windows 10, Windows Server 2016 и другие.
Однако после дальнейшего расследования Форшоу определил, что хотя патч и смягчает последствия эксплойта PoC, он не устраняет основную проблему, поэтому является неполным. Исследователь безопасности разработал новый PoC, чтобы продемонстрировать, что эксплойт все еще возможен, и сообщил о нем в Microsoft 18 июня. Однако, учитывая, что отведенные 90 дней истекли 23 июня без полного исправления, эксплойт был обнародован. Учитывая, что это локальный вектор атаки с низкой вероятностью эксплуатации, вполне вероятно, что Microsoft выпустит полное исправление в следующий вторник исправлений, который выпадает на 13 июля. Однако пока это не подтверждено.
