Internet Explorer формально давно перестал быть браузером, которым пользуются каждый день. Но в Windows он не исчез бесследно. В докладе «Internet Explorer не забыт» Игорь Сак-Саковский разбирает именно этот зазор между публичным ощущением «IE умер» и практической реальностью: движок, модели доверия и старые интеграции продолжают жить внутри desktop-приложений, WebBrowser Control, .NET-компонентов, старых обработчиков файлов и системных сценариев открытия ссылок.
Фокус доклада был не на очередной ностальгии по Internet Explorer, а на client-side-атаках в среде Windows. Спикер прямо обозначил свой угол зрения: XSS, Universal XSS, clickjacking, странные переходы между security zones, неожиданные ActiveX-поверхности и цепочки, где веб-контекст внезапно начинает взаимодействовать с локальной машиной. Это exploit-heavy материал, но главный практический вывод защитный: если desktop-приложение на Windows рендерит HTML через WebBrowser Control или похожую legacy-интеграцию, его нельзя оценивать как «просто UI». Иногда это полноценная браузерная поверхность с доступом к наследию Internet Explorer.
Почему IE важен после смерти IE
Internet Explorer как пользовательский продукт был выведен из эксплуатации, но WebBrowser Control остался важным совместимостным слоем. Им пользовались и продолжают пользоваться desktop-приложения: почтовые клиенты, просмотрщики документов, редакторы таблиц, вспомогательные окна, рекламные баннеры, старые корпоративные инструменты, плагины и компоненты на .NET или VBS.
Это меняет модель угроз. Уязвимость может находиться не в «браузере» в привычном смысле, а в приложении, которое:
- принимает файл или письмо;
- преобразует документ в HTML;
- показывает HTML через WebBrowser Control;
- разрешает часть JavaScript;
- наследует поведение Internet Explorer, security zones и ActiveX;
- открывает внешние схемы, file://, localhost или системные обработчики файлов.
Вопрос уже не в том, установлен ли у пользователя Internet Explorer как браузер по умолчанию. Вопрос в том, есть ли в приложении старый HTML-rendering-компонент, какие security zones он получает и какие системные интеграции доступны из этого контекста.
Security zones как центральная ось
Одна из главных линий доклада — security zones. В Internet Explorer и Windows разные источники контента исторически получали разные уровни доверия: интернет-сайты, доверенные сайты, недоверенные сайты, локальные файлы, My Computer. Но на практике появляются промежуточные зоны и особые режимы: localhost и SMB share могут вести себя не так, как обычный сайт из интернета, но и не совсем так, как локальный file://.
Именно на этих границах рождаются интересные цепочки. Интернет-страница сама по себе ограничена. Локальный файл получает больше возможностей. localhost оказывается особенно опасным, если на нем есть уязвимое приложение или если desktop-приложение создаёт локальный веб-интерфейс. SMB share добавляет сетевую доставку и взаимодействие с Windows-механиками, включая утечки NetNTLM в некоторых сценариях.
Для защитника это важнее конкретной демонстрации: проверять нужно не только «есть ли XSS», а куда эта XSS попадает. XSS в обычном сайте и XSS внутри WebBrowser Control, который может открыть file:// или дёрнуть системный обработчик, — разные классы риска.
ActiveX: старая поверхность с разными уровнями доступа
ActiveX в докладе выступает как пример того, что «старое» не равно «неиспользуемое». В Internet Explorer ActiveX-объекты зависят от зоны, из которой запускается страница. У интернет-сайта доступен ограниченный набор. У localhost — шире. У локальных файлов — ещё шире, вплоть до небезопасных объектов, требующих отдельного подтверждения.
В одном из показанных сценариев цепочка строилась вокруг перехода из веб-контекста в локальный файл, где становятся доступны более сильные ActiveX-возможности. Сам по себе Internet Explorer не хотел автоматически сохранять файл без пользовательского действия, но связка с Microsoft Edge давала другой путь: IE мог открыть Edge через схему microsoft-edge:, а Edge уже сохранял файл в локальную папку. Затем Internet Explorer возвращался к сохраненному файлу и пытался выполнить его в более доверенном контексте.
Ключевой защитный нюанс здесь — Mark of the Web. Если файл скачан из интернета, Windows помечает его как пришедший из внешней зоны. Это влияет на предупреждения и ограничения при запуске. Но при загрузке с localhost поведение менялось: файл мог не получать Mark of the Web и воспринимался как созданный локально. Так цепочка из Internet Explorer, Microsoft Edge, локального файла, ActiveX и Windows Security Warning превращалась в «RCE через клики», где пользователь видел предупреждения, но сама возможность возникала из-за комбинации старых доверительных границ.
RCE через клики, а не через один волшебный баг
В докладе несколько раз звучала идея «10-click RCE» и «RCE через clickjacking». Это не обязательно один идеальный zero-click-баг. Скорее это набор слабых мест, где каждое по отдельности выглядит ограниченным, но вместе они дают выполнение кода при участии пользователя.
Упрощённая логика одной из цепочек такая:
- пользователь попадает на attacker.com или открывает контент в уязвимом desktop-приложении;
- XSS исполняется в более интересном контексте, например на localhost или внутри WebBrowser Control;
- цепочка сохраняет или подсовывает файл;
- происходит переход в file:// или локальную директорию;
- запускается ActiveX, обработчик файла или системный компонент;
- Windows показывает предупреждения, а clickjacking и управление фокусом пытаются превратить действия пользователя в подтверждения.
Такие цепочки неприятны тем, что их трудно классифицировать. Для браузерной команды это может выглядеть как «пользователь сам кликнул». Для команды desktop-приложения — как «это поведение Windows». Для Windows — как legacy-совместимость. Но для атакующего это единая поверхность.
Запуск сторонних процессов и обработчики файлов
Отдельный блок был посвящён тому, что Internet Explorer и WebBrowser Control могут неожиданно передавать файлы внешним приложениям. Спикер описывал, как при открытии некоторых расширений файл не отображался внутри IE, а сохранялся во временную папку и открывался связанным процессом. Так были перебраны расширения Windows и выделены интересные группы обработчиков.
Самой заметной оказалась группа playlist-файлов, открываемых через Windows Media Player. Плейлисты интересны не как медиаконтент, а как формат, который обрабатывается другой библиотекой и может обращаться к file:// или сетевым ресурсам иначе, чем обычная веб-страница. В показанной идее Windows Media Player получал playlist и мог сходить на SMB share, что вело к утечке NetNTLM.
С точки зрения защиты это классический пример «второго интерпретатора». Приложение думает, что открыло безобидный файл или ссылку. Но дальше управление получает другой компонент — Windows Media Player, Office, ClickOnce, XAML-движок или обработчик ярлыков. У каждого свои правила доверия, свои предупреждения и свои старые исключения.
.NET-форматы: XAML, VSTO, Application/ClickOnce, XBAP
Ещё одна группа демонстраций касалась форматов, связанных с .NET:
- XAML;
- VSTO;
- Application/ClickOnce;
- XBAP.
XAML в докладе выглядел самым ограниченным: через XML и namespace можно было дотянуться до некоторых .NET-классов и методов, но попытки выйти в сеть, читать произвольные файлы или запускать процессы упирались в permission error. Это важное отличие: наличие интерпретируемого формата не означает автоматический RCE, но означает поверхность, которую нужно проверять.
VSTO оказался опаснее как механизм Office-плагинов. В демонстрации VSTO-файл запускался через Internet Explorer, показывал собственное предупреждение установщика, после чего код выполнялся уже при запуске Excel. Application/ClickOnce вел себя похожим образом, но запускался как приложение после согласия пользователя. XBAP работал как внутрибраузерное приложение с собственной моделью предупреждений.
Интересный вывод: часть этих форматов можно было запускать не только из Internet Explorer, но и из Microsoft Edge, пусть и с дополнительными подтверждениями. Это снова показывает, что замена браузера не всегда убирает legacy-поверхность, если системные ассоциации файлов и доверительные решения остаются прежними.
Universal XSS через MHTML/MHT
Самый «браузерный» эпизод доклада — Universal XSS через web archive, то есть MHTML/MHT. Этот формат позволяет сохранить страницу одним файлом: внутри лежит основной HTML и связанные ресурсы. Чтобы браузер понимал, откуда эти части происходят, используются служебные заголовки вроде Content-Location. Для внутренних ссылок может использоваться Content-ID и cid:.
Проблема возникает, когда архив начинает влиять на происхождение содержимого. По описанию спикера, Content-Location мог заставить Internet Explorer воспринимать часть архива так, будто она пришла с другого домена, а относительные пути и cid:-ссылки помогали собрать выполнение JavaScript в чужом origin. В демонстрации результатом становился доступ к cookie сайта, то есть Universal XSS.
Здесь особенно важно не превращать идею в рецепт: ценность для защитника в том, что архивные форматы — это не «пассивные документы». MHTML/MHT сохраняет не только байты страницы, но и метаданные происхождения. Если движок неправильно восстанавливает origin, архив превращается в механизм обхода Same-Origin Policy.
Листинг папок, Shell.Explorer.2 и clickjacking
В докладе был показан ещё один класс поведения, который спикер называл «не баг, а фича»: листинг папок Windows внутри IE-подобного контекста. Iframe мог отображать содержимое директории примерно как проводник: файлы, папки, контекстное меню, двойной клик, запуск.
Если такой список можно встроить во фрейм, уменьшить, сделать невидимым или расположить под курсором, появляется clickjacking. Пользователь думает, что кликает по одному элементу страницы, а на самом деле взаимодействует с файловым представлением. В демо цепочка включала сохранение архива, HTML-файлы рядом с исполняемым файлом и переходы, которые приводили к запуску через интерфейс листинга.
Особенно показателен компонент Shell.Explorer.2. При изучении DOM спикер увидел не обычный HTML, а ActiveX-объект с параметрами. Один из параметров, SingleClick, намекал, что поведение можно изменить с двойного клика на одиночный. Даже если конкретные демо требовали подтверждений и кликов, сама архитектура опасна: файловый менеджер оказывается встроенным в веб-поверхность.
Drag-and-drop и обход Mark of the Web
Финальный крупный блок был посвящён drag-and-drop. Mark of the Web обычно должен предупреждать пользователя: файл пришёл из интернета, запускать его опасно. Но не все способы запуска и копирования проходят через одинаковые проверки.
Один сценарий касался LNK-файла внутри zip-архива. Если запускать такой ярлык обычным двойным кликом, Windows показывает предупреждение. Но при drag-and-drop другого файла на этот ярлык путь обработки отличался, и предупреждение могло не сработать. Другой сценарий был связан не с запуском, а с копированием: файлы с SMB share при обычном копировании должны получать Mark of the Web, но некоторые drag-and-drop-цели могли создавать ярлык на Desktop или в Documents без ожидаемой метки.
В транскрипте упоминались цели вроде MyDocs, Desktop.ini и DeskLink, но их точные имена восстановлены не полностью. Поэтому важнее общий вывод: MotW — это не магический флаг безопасности, который автоматически покрывает все пути доставки. Нужно проверять не только скачивание из браузера, но и zip, SMB share, drag-and-drop, LNK, shell extensions и все нестандартные способы копирования.
Что это значит для desktop-приложений
Главный урок доклада — desktop-приложения на Windows нельзя проверять только как «локальный клиент». Если внутри есть HTML, WebBrowser Control, встроенный просмотрщик документов, преобразование файлов в HTML или локальный web server на localhost, приложение становится частью браузерной модели угроз.
Практические выводы для разработчиков и защитников:
- не использовать WebBrowser Control для отображения недоверенного HTML; если нужен webview, выбирать современный компонент и жёстко настраивать изоляцию;
- считать XSS в desktop-приложении критичнее обычного alert(1), потому что контекст может быть ближе к localhost, file:// или локальным обработчикам;
- запрещать или фильтровать переходы к file://, SMB share и опасным внешним схемам;
- проверять, какие ActiveX-объекты доступны из каждого контекста;
- отдельно тестировать Mark of the Web для Edge, IE, zip-архивов, SMB share, LNK и drag-and-drop;
- рассматривать Windows Media Player playlist, MHTML/MHT, XAML, VSTO, Application/ClickOnce и XBAP как активные форматы, а не как нейтральные файлы;
- не полагаться только на предупреждения Windows Security Warning, если интерфейс допускает clickjacking или управление фокусом;
- анализировать цепочки целиком, потому что слабое место часто находится не в одном компоненте, а на границе между ними.
В конце доклада прозвучала важная формулировка: это борьба за клики и борьба с Mark of the Web. Не всё показанное было «однокликовым» или бесшумным, но это не делает материал менее важным. Напротив, такие цепочки часто выживают именно потому, что каждая отдельная часть выглядит допустимой: пользователь кликнул, файл открылся штатным обработчиком, предупреждение было показано, WebBrowser Control нужен для совместимости.
Internet Explorer не забыт не потому, что кто-то продолжает запускать iexplore.exe по привычке. Он не забыт потому, что его идеи, API, зоны доверия и системные интеграции продолжают жить в приложениях, которые пользователи считают обычными Windows-программами.