Shatter attack

Тема shatter attack привлекла широкий интерес в сообществе специалистов по безопасности в августе 2002 года после публикации работы Криса Паджетта под названием «Exploiting design flaws in the Win32 API for privilege escalation». В статье, в которой впервые был использован термин «shatter attack», описан процесс, при котором приложение может выполнять произвольный код в другом приложении. Это становилось возможным, поскольку Windows разрешает непривилегированным приложениям отправлять сообщения в цикл сообщений приложения с более высоким уровнем привилегий, причём некоторые сообщения могут содержать адрес функции обратного вызова в адресном пространстве приложения в качестве параметра. Если злоумышленнику удаётся поместить свой шелл-код в память привилегированного приложения (например, вставив его в поле ввода) по известному адресу, он отправляет сообщение WM_TIMER, передавая в параметрах адрес внедрённого шелл-кода. Система без проверки воспринимает этот адрес как легитимную функцию обратного вызова (TimerProc) и передаёт ей управление, в результате чего вредоносный код выполняется с правами целевого процесса^[3].

Спустя несколько недель после публикации данной работы компания Microsoft прокомментировала проблему следующим образом: «В статье верно указано, что такая ситуация существует, и верно описано её влияние. … Ошибка же заключается в утверждении, что это недостаток Windows. На самом деле, проблема заключается в конкретной высокопривилегированной службе. По замыслу, все службы в интерактивном рабочем столе — равноправные участники и могут делать друг другу запросы. В результате, все службы интерактивного рабочего стола фактически располагают привилегиями, соответствующими самой высокопривилегированной службе.»

В декабре 2002 года Microsoft выпустила обновление для Windows NT 4.0, Windows 2000 и Windows XP, устранившее некоторые способы эксплуатации этой уязвимости. Однако это было лишь частичным решением, поскольку исправление распространялось только на сервисы самой Windows, подверженные такому способу атаки; базовый изъян архитектуры оставался и мог быть использован для атаки на другие приложения или сторонние службы. В Windows Vista компания Microsoft решила проблему двумя способами: во-первых, локальные пользователи больше не входят в систему в сеанс с номером 0, тем самым разделяя цикл сообщений пользовательской сессии и системных служб с высокими привилегиями, загружаемых в Session 0. Во-вторых, была добавлена функция изоляции привилегий пользовательского интерфейса (UIPI), позволяющая защищать процессы от shatter attack путём присвоения каждому процессу уровня целостности. Попытки отправить сообщения процессу с более высоким уровнем целостности будут отклонены, даже если оба процесса принадлежат одному пользователю. Тем не менее, не все взаимодействия между процессами с разными уровнями целостности блокируются механизмом UIPI. Например, Internet Explorer 7 использует UIPI для ограничения возможностей компонент отображения взаимодействовать с остальной системой. Механизмы изоляции привилегий пользовательского интерфейса (UIPI) и обязательный контроль целостности (MIC) остаются фундаментальными компонентами безопасности в современных системах, включая Windows 11 на 2026 год^[4].

Архитектура создания сессий была переработана в Windows Vista и Windows Server 2008 для дополнительной защиты от shatter attack: вход локальных пользователей был перенесён из сеанса 0 в сеанс 1, тем самым процессы пользователя были изолированы от системных служб, потенциально подверженных атаке^[5].

Однако такая схема приводит к проблемам обратной совместимости, поскольку часть программного обеспечения была рассчитана на работу службы в одной сессии с вошедшим пользователем. Для поддержки такого сценария в Windows Vista и Windows Server 2008 была введена служба Windows «Interactive Services Detection», позволяющая пользователю открывать диалоги, созданные интерактивными службами. Пользователю показывалось окно с предложением переключиться в сеанс 0 для взаимодействия с диалогом^[6]. Помимо Windows 10, служба обнаружения интерактивных служб (UI0Detect) была полностью удалена в Windows Server 2022 и Windows Server 2025, что сделало нулевую сессию строго неинтерактивной и дополнительно усилило защиту^[7][8]. Для взаимодействия фоновых служб с пользователем в современных операционных системах (включая Windows 11) Microsoft рекомендует использовать разделение на службу и GUI-приложение с обменом данными через механизмы межпроцессного взаимодействия (IPC), либо применять функции WTSSendMessage и CreateProcessAsUser^[8].