# Internet Explorer не забыт

Доклад: «Internet Explorer не забыт»
Спикер: Игорь Сак-Саковский

## Вступление

Всем привет! Меня зовут Игорь Сак-Саковский. Сегодня я буду рассказывать доклад про баги в Internet Explorer, как вы уже могли заметить. Я решил назвать его «Internet Explorer не забыт».

Вкратце о себе. Я client-side-фил. Очень люблю client-side-баги: XSS, всякие alert(1), alert(document.cookie) — это все мое. Я не компилирую, поэтому баги будут очень странными. Возможно, в какой-то момент покажется, что я натягиваю сову на глобус, но на самом деле это дикий client-side, назовем его так.

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

Будет много «10-click RCE», будет RCE через clickjacking — это главная тема доклада. Будет Universal XSS, что в последнее время редкость, но техника, которая привела к Universal XSS, супердревняя. И, что немаловажно, не все баги исправлены. Этот доклад можно использовать как гайд для взлома desktop-приложений на Windows. Microsoft разрешила публиковать неисправленные [неразборчиво], поэтому все нормально, все прилично.

## Предыстория: desktop-приложения и JavaScript

Небольшая предыстория. Года четыре назад я сильно-сильно стал врываться в desktop-приложения: почтовые клиенты и вообще все, что есть на desktop на Windows, куда можно как-то пропихнуть XSS или JavaScript.

В одной из почт — я не могу назвать ее, потому что они там не исправили, как обычно, — я искал баги и записывал их в заметки. В одной из почт я нашел баг, который мне показался сложно эксплуатируемым. Вообще, моя цель была не просто сделать alert(1), а добраться до файлов или до запуска процесса, до чего-то совсем необычного.

В одной из почт у меня не получалось ни один из методов выполнить, наподобие window.open или location, чтобы [неразборчиво] главное окно. Но встроенный showModalDialog у меня заработал. Более того, он позволил открыть ссылку со схемой file://, что совершенно необычно для современного браузера.

## Баг с двумя URL и доступом к локальным файлам

Второй шаг — маленький кусочек кода. Самая главная часть в том, что мы вызываем через window.open две URL-ки. Первая вообще какая-то поломанная, вторая — понятная.

Что происходит? Когда вызываешь первую URL-ку, Internet Explorer говорит: «Нет, какая-то она сломанная, я не могу ее открыть, тебе нужно нажать кнопочку “OK” и согласиться, что это действительно сломанная URL-ка». А после этого, когда ты нажимаешь OK, вот эта URL-ка, на которую он вообще не должен ходить, становится доступной, и он может начинать ходить в локальные файлы.

При этом, если открыть URL-ки быстро одну за другой, эта popup-плашка со сломанной URL не всплывает. Процесс полностью автоматизируется.

Что мы получаем в этих багах? Мы можем ходить, грубо говоря, из интернета в локальные файлы.

А что нам это в целом даст? Даст много чего интересного. В Internet Explorer внедрено очень много штук из Windows — не из инфраструктуры Windows, а из экосистемы Windows.

Для многих, наверное, знакомо такое словосочетание, как security zones. В Windows пять security zones, насколько я помню. Первая — My Computer, вторая — сайты в интернете, третья — trusted zone, когда ты сам добавляешь доверенные сайты, потом untrusted — это тоже ты сам добавляешь, и, по-моему, просто сайты в интернете.

Помимо этого, я обнаружил, что localhost и SMB share — как будто какая-то вообще отдельная security zone, которая ни туда ни туда не относится. Потому что она вроде может больше, чем сайт в интернете, но не может столько же, сколько локальные файлы.

## ActiveX и локальные файлы

Что конкретно вообще могут локальные файлы?

Сайты в интернете могут запускать такую штуку — ActiveX. Это как JavaScript, но не на максималках, а скорее как плагины для JavaScript: через JavaScript появляется небольшая API-шечка, и ты можешь обращаться к библиотеке.

У сайтов в интернете доступно очень мало всяких ActiveX-объектов. У сайтов на localhost доступно намного больше. А у локальных файлов, когда ты из локального файла запускаешь какую-то страничку, доступно максимально много, даже самые небезопасные.

И вот как это выглядит. Это уже вторая часть. До этого я рассказывал, что нашел баг в почтовом клиенте. Теперь я нашел баг... А, еще не нашел.

В общем, я буду открывать локальный файл, но мне его нужно как-то сначала положить либо положить в него контент. Так как я рассказывал про Internet Explorer, самое логичное было попробовать заставить его сохранить какой-то файл. Но, к сожалению, Internet Explorer автоматически это сделать не умеет: он просит подтверждения. Поэтому этот момент мы пропускаем.

## Edge как способ сохранить файл

Вторая часть бага, когда у меня все сложилось: я ломал уже не почтовый клиент, а редактор таблиц, типа Excel. Воткнул туда JavaScript, и у меня всплыл Windows Security Warning. Это говорит о том, что действительно ActiveX-объект запустился, он небезопасный, и для его инициализации пользователь должен согласиться, подтвердить.

Каким образом я этого добился? Оказывается, Internet Explorer не умеет сам сохранять файлы: ему нужно нажимать на кнопочки. Но он может открывать окошко Microsoft Edge через схему microsoft-edge: и дальше просто ссылку на нужный сайт.

А Microsoft Edge уже, в свою очередь, может спокойно сохранить файлы в локальную папочку. И мы складываем одно со вторым, получаем полную цепочку: кладем файл и его запускаем.

Немного тонкостей про эту штуку с сохранением файлов. Первый раз, когда я сделал все вместе, сложил цепочку, я использовал файл с localhost. У меня все окей, все сработало: всплыло окошечко Windows Security Warning.

Когда я уже делал отчет, я делал более реалистичные условия: прописал себе host attacker.com, заменил localhost, и при этом у меня уже не всплыл небезопасный ActiveX-объект. Когда я начал копаться, я обнаружил, что если скачивать файл с localhost, на него не ставится меточка Mark of the Web. Он считается как будто созданным локально, а не скачанным откуда-то.

## Цепочка 1: 10-click RCE со страшными popup

Это даже не баг, а цепочка номер один: 10-click RCE со страшными popup.

Логика такая. У нас есть сайт attacker.com, куда пришел пользователь. Этот сайт открывает либо заранее уязвимое приложение, например какой-нибудь uTorrent, где недавно обнаружили XSS, и пытается с помощью XSS нагрузить и нагрузить.

Либо эти два момента можно сложить в один: если ты нашел XSS в каком-то почтовом клиенте, у тебя уже может быть либо localhost, либо сразу file://, как здесь. Тогда шаги немного упрощаются, и мы уже сразу попадаем в нужный контекст.

Что здесь происходит? Attacker.com открывает XSS на localhost. XSS на localhost открывает Edge, сохраняет файл, а потом возвращается и редиректит Internet Explorer на этот сохраненный файл.

Вот так это выглядит все вместе. Открылся Edge, сохранился файл, редирект, и сейчас будут всплывающие окошки. В Internet Explorer два всплывающих окошка: нижнее и верхнее. Нижнее — чтобы включить в целом JavaScript для локального файла, а второе — уже чтобы запустить небезопасный блок.

Нижнее всплывающее окошко можно забайпасить, я уверен на 95%. А вот второе уже [неразборчиво].

## Баг 2: запуск сторонних процессов

Баг номер два: abuse запуска сторонних процессов.

Как оказалось — я точно не могу утверждать, потому что, как я уже говорил, я не умею компилировать, — я интересуюсь: есть ли у Internet Explorer песочница? Если есть, она почему-то позволяет спокойно запускать сторонние процессы. Я ее вообще не наблюдаю.

Способ запуска процессов абсолютно тупой. Кто HTML знает: мы просто открываем не локальный файл, а файл с localhost. Вместо того чтобы открыться в окне Internet Explorer, он сохраняется во временную папку, запускается процесс notepad.exe и подтягивает этот файл, открывая его у себя.

Когда я это обнаружил — чисто случайно, просто CSS-файлик пытался открыть, — и когда обнаружил, что у меня всплыл процесс, я написал fuzzer, который просто перебрал у меня все extensions из Windows. Я получил небольшую табличку. Сзади сидеть плохо видно, но дальше будет выжимка.

Самое интересное и важное, что больше всего зацепилось: у нас есть группа файлов, которые отвечают за плейлисты. Они запускают процесс Windows Media Player, который тоже поможет.

С localhost, как я уже показывал, можно запустить просто редиректом, открыв test.wmx. Но при этом с любого сайта мы можем с помощью ActiveX-объекта запустить библиотеку Windows Media Player и скормить ей также ссылочку на плейлист. И это будет работать уже не только на localhost, а вообще на любом сайте.

Чем нам интересны плейлисты? Тем, что, так как они обрабатываются уже другой библиотекой, у них нет ограничений на то, что они могут ходить на ссылки file://. И мы можем при воспроизведении плейлиста сходить на SMB-шару и leak-нуть NetNTLM пользователя.

## .NET: XAML, VSTO, Application, XBAP

Продолжим. Помимо Windows Media Player, там еще было четыре интересных расширения: XAML, VSTO, Application и XBAP. Они позволяют дотянуться и немного пощупать .NET-классы.

Самый более защищенный, менее небезопасный, наверное, XAML. Выглядит он вот так: это просто XML-файлик, который открывается в Internet Explorer. Я тут не успел разметить, но вкратце: через namespace инициализируется System.Runtime, дальше мы обращаемся к классу String и вызываем у него всякий Concat, IndexOf и все такое.

Вот как это выглядит на domain [неразборчиво] Explorer. Мы просто открываем, к сожалению, не видно, сам файл. Первое — это длина, потом Concat, потом индекс такого-то символа.

Естественно, я попробовал запускать всякие небезопасные вещи. Единственное, что у меня получилось, — это просто popup вызвать. Когда я попробовал DNS-запрос отправить или сделать, грубо говоря, какой-то leak IP-шника хотя бы, у меня вывалилась System.Net permission error. Когда я попробовал прочитать файлы и запускать какие-то процессы вне директории: процессы вообще запускать не позволяем, файлы читаются только в корневой директории. Если выходишь из нее — опять же permission error.

Следующее расширение файлов — VSTO. Это плагины для Office.

Самый главный кусочек кода выглядит так: открываешь среду разработки, вставляешь, там что-то все собирается, и в итоге получается гигантское полотно из непонятных мне XML-элементов, которые подписаны Digital Signature и ссылаются вот здесь на manifest и на DLL: ExcelAddIn.dll.

Что будет, если мы откроем такой файлик в Internet Explorer? Если мы скачиваем файл из интернета и запускаем, обычно у нас вот такое окошко выскакивает. Это как раз говорит о том, что у файла есть Mark of the Web и его расширение небезопасное. Но у этой группы файлов такого оповещения нет: у них есть свои собственные встроенные оповещения.

Вот как это выглядит. Запускаем VSTO через Internet Explorer. Вот такое оповещение. Я сейчас покажу, на что конкретно он ругается: publisher, какой-то machine access — это, видимо, то, что я код выполняю. Я нажал Install. Close можно не нажимать.

Теперь, чтобы наш код запустился, так как мы установили это как плагин к Office, нам нужно просто открыть Excel. Все, при запуске Excel выполняется код.

Еще раз покажу: тут есть обработчик события startup. Я просто туда дописал: запускай Calculator при startup.

Следующее расширение — Application. Это уже ClickOnce-приложение. Плюс-минус код похожий. Вот так выглядит, когда его запускаешь. Вообще, я его запускаю двойным кликом, но можно просто редиректом запускать. Это так, для наглядности. Ошибки плюс-минус те же самые, но теперь нам не нужно ничего запускать: оно сразу запустится после того, как нажимаешь согласиться.

Теперь третье — XBAP. Это уже внутрибраузерное приложение. И почему-то здесь в ошибке уже, по-моему, installation или что-то такое.

Самое главное — бонус: XAML, Application и XBAP можно запускать из Microsoft Edge, не только из древнего Internet Explorer. Но сейчас он проиграет. Единственный момент: теперь нам нужно не два клика, чтобы согласиться по этому оповещению, а еще сверху всплывает [неразборчиво]. Вот здесь нужно первый клик сделать, а потом еще второй по обычному оповещению.

## Universal XSS через web archive

Universal XSS через web archive.

Для многих, наверное, знаком такой формат, как MHTML или MHT. Если открыть в браузере Ctrl+S — такое сочетание клавиш, — можно выбрать «сохранить не как много файлов», а сохранить одним файлом. Это как раз сохранится в таком формате.

Как вообще работает этот web archive? Так как мы репрезентуем в одном файле много разных файлов, мы обязаны как-то указать, где до этого находился этот файл. За это у нас отвечает заголовок Content-Location. Он показывает, где файл лежал до того, как мы скачали этот архив.

Помимо этого, есть еще RFC, где мы можем передать заголовок Content-ID со значением. И этот заголовок будет использован для того, чтобы какой-то кусочек загрузить в основной файл с помощью URL-ки cid:. То есть мы передаем Content-ID — сейчас покажу на примере — и test в угловых скобках. Потом используем просто cid:test и загружаем файл с этим Content-ID.

Итак, в целом вот полностью эксплойт, который приводит к выполнению JavaScript на одном сайте. Что мы должны здесь увидеть? Вот эта стрелочка показывает, как Content-ID отображается. Эта стрелочка показывает, как мы открываем этот Content-ID.

Content-Location у нас перезаписывает. Делает так, как будто файл мы скачали с msn.com. Потом через относительные пути он ходит и пытается уже выполнять скрипты.

Как это выглядит? В целом точно так же, как и первый баг. Только теперь нам нужно кликнуть еще раз, потому что Edge не может автоматически скачать MHT: он считает это очень безопасным. Думаю, это тоже как-то можно обойти.

В общем, файл скачался, автоматически с редиректился, у нас cookie с msn.com показывается.

## Баг 4: листинг папок в Windows и clickjacking

Четвертый баг — не баг, а фича. Все, что я называю «не баг, а фича», означает, что это не исправлено. То, что «баг», означает, что исправлено.

Четвертый баг: abuse листинга папок в Windows.

Как это выглядит? Я вывел три окошка с iframe, они вывели названия файлов, папок и все дела. По сути, этот функционал полностью эмулирует функционал проводника explorer.exe. Также работает нажатие правой кнопки мыши: скопировать, переименовать. Также работает запуск двойным кликом.

И самое главное: мы можем эти фреймы делать маленькими, делать невидимыми, укладывать друг на друга. Это приводит как раз к clickjacking-атаке.

Что у нас получается? Все точно так же: attacker.com открывает localhost XSS. localhost XSS сохраняет теперь уже zip-архив. В zip-архиве у нас лежит HTML-файл, который мы используем как [неразборчиво], чтобы она открыла нужное. И рядом с HTML-файлом у нас лежит EXE-шник.

Так как мы качаем его с localhost, Mark of the Web не ставится, и мы можем из этого zip-архива автоматически запустить EXE-шник. Ну не автоматически, а через взаимодействие. Вот так это выглядит: у нас дропается HTML, дропается zip-архив, две HTML. Нам нужно цепочку сделать, чтобы красиво это было. Редирект — и теперь у нас всегда под курсором бегает квадратик.

Вот видно на черном [неразборчиво]. Если два раза кликнуть по квадратику, у нас без каких-либо оповещений, без этих соглашений, просто сразу же запустится [неразборчиво].

Я поковырял немного это место и попытался его апгрейдить. Как я это сделал? Я просто открыл исходный код страницы и увидел, что обычно здесь в iframe исходный код страницы, которую ты открыл, а у меня здесь вообще ActiveX-объект какой-то загрузился.

Я попробовал редактировать эту DOM. Видно там ProgID Shell.Explorer.2 и ClassID тоже указан отдельно. Я попробовал провалиться внутрь этого объекта, нажал «Редактировать», и он мне вывалил список всех своих параметров.

Самый главный параметр, за который у меня зацепился взгляд, — SingleClick. Он как бы намекает, что мы можем теперь запускать не двумя кликами.

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

Так это выглядит: также скачивается пара HTML и zip-архив. У меня на виртуалке заглючило видео, мы долго видео записывали. И нам нужно согласиться сначала здесь — я уже говорил, что это, скорее всего, можно обойти, — а потом еще сделать этим клик куда-нибудь. Все, [неразборчиво] запускается.

## Drag-and-drop и обход Mark of the Web

Следующий пример уже совсем необычный. Помимо запуска с помощью длинных кликов, мы можем перетаскивать файлы друг на друга. В этом случае нам уже не нужен localhost как доставка файла, потому что мы можем обходить Mark of the Web.

Как это работает? Мы можем создать zip-архив с LNK-файлом. Я покажу настройки LNK-файла, которые использовал: указать ему просто запуск командной строки с аргументом calc.exe.

Обычно, если такой файл скачан из интернета, по нажатию на него всплывет оповещение Mark of the Web: вы действительно хотите запустить файл из интернета, которому мы не доверяем?

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

Я видео очень [неразборчиво], пардон. Только самое завершающее видео. В общем, первый был так: мы перетаскиваем просто на LNK, и из-за того, что используем необычный способ запуска, это обходит проверку Mark of the Web.

Второй способ обойти проверку Mark of the Web — уже не при запуске, а при копировании файлов.

Как я вообще это обнаружил? Изначально я тестировал не все по архивам, а поднял SMB-шару и оттуда пытался файлы скопировать, перетащить или что-то такое сделать. Я обнаружил несколько расширений файлов, которые зарегистрированы в Windows как цель для drag-and-drop. То есть на них нужно перетаскивать что-то.

Первое — .mapimail. Открывается Outlook, и этот файл улетает во вложение в новом письме. Можно еще нажать потом «Отправить». Не особо интересно.

MyDocs и Desktop.ini более-менее интересны, потому что они создают ярлык на перетаскиваемый файл в Documents либо на Desktop. И последнее — архивируют файл просто через [неразборчиво].

Самое интересное, что больше всего меня заинтересовало, — создать файл на Desktop, потому что это все время перед лицом у пользователя.

В данном случае я опять же делаю все через zip-архив. Сейчас будет видно, что этот способ действительно рабочий и Mark of the Web устанавливается. Сейчас объясню, как это делать, чтобы Mark of the Web не устанавливался.

Опять же, это можно абсолютно игнорировать. Перетаскиваем, у нас появляется на рабочем столе ярлычок на localhost. Мы по нему кликаем — вот это оповещение Mark of the Web.

Как его обойти? На этом этапе нам теперь не нужно скачивать zip-архив. Мы можем открыть SMB-share.

Получается как? Когда ты качаешь zip-архив, все вложенные в него файлы автоматически наследуют Mark of the Web. Когда у тебя файл лежит на шаре, ты по нему кликаешь два раза, он сначала не имеет никакой Mark of the Web. Ты по нему кликнул — он куда-то улетел во временную папку Windows, в этот момент установился Mark of the Web и уже запустился.

Если скопировать — то же самое: файл улетает в папку, куда ты его хотел положить, например на рабочий стол, устанавливается Mark of the Web, и такое же оповещение должно всплывать.

Однако если мы берем LNK-файл, то есть уже [неразборчиво], перетаскиваем на DeskLink с SMB-шары, то из-за того, что у нас необычный способ копирования, он не завершается установкой Mark of the Web. Поэтому оповещение «действительно хотите запустить файл?» не показывается.

Вот как раз я описываю это текстом.

На этом все. Я уверен, что я немного сумбурно рассказал, и какие-то вопросы могут появиться, поэтому welcome.

## Вопросы

— А когда эксплуатировали [неразборчиво], в итоге там было RCE?

— Да, в итоге там было RCE, но оно требовало, опять же, чтобы на localhost было приложение. Там сложно было бы эксплуатировать.

Суть в чем: доставлялось все через Excel-файлы. Я в него дописывал HTML-код в определенное место. Когда его открывал редактор, этот HTML-код добавлялся в страницу, рендерился и запускал уже скрипты.

Excel-файл был способом доставки, а баг был в необычном просмотрщике Excel-файлов. Он сначала превращал Excel в HTML, потом выводил с помощью browser, поэтому там были баги.

— [Вопрос неразборчиво: про то, что это не любой Excel-файл?]

— В самом Excel, скорее всего, таких багов уже не будет. Это уже давным-давно было. Это больше... опять же, вернемся в начало: весь этот доклад — это способ ломать всякие desktop-приложения.

А вот, я, кстати, забыл важную мысль. Internet Explorer выпилили в 2022 году — тоже ни для кого не секрет. Но он все так же используется в desktop-приложениях в виде WebBrowser Control, компонента .NET и VBS.

Тот же самый WinRAR, который я года три-четыре назад ломал и писал про это, использует как раз WebBrowser Control в одной из трех запусков. То есть ты запускаешь просто архивчик или запускаешь EXE-шник. Он считает: три раза прошло, если у тебя не оплачена лицензия, говорит: «Давай-ка ты оплатишь лицензию», — и показывает тебе баннер. Как раз этот баннер грузит WebBrowser Control со своего сайта и показывает HTML-баннер.

— Мне кажется, следов мало остается. У тебя по чуть-чуть весь доклад — борьба с Mark of the Web.

— Борьба за клики, борьба с Mark of the Web.

— Есть достаточно известная техника: мы скачиваем подписанное приложение и рядом DLL, подбираем DLL hijacking. Да, мы bypass-им Mark of the Web. Погугли просто OneDrive DLL hijacking.

— Спасибо. Надо будет посмотреть, попробовать.

— Говори громче, не слышу.

— Сейчас, в ближайшее время, мы выложим на [неразборчиво] статью полностью. [неразборчиво].

Все? Спасибо, что послушали.

## Неоднозначные места

- Во вступлении ASR распознал имя как «Илья Кэйс Исаковский»; по переданному контексту спикер указан как Игорь Сак-Саковский.
- Фраза про разрешение Microsoft публиковать неисправленные «аудитории» неразборчива; смысл оставлен без уточнения.
- Несколько раз неразборчивы короткие слова вокруг демонстраций на видео: что именно «запустится», «подсюш», «закручивает», «на черное ножи».
- Названия некоторых демонстрационных файлов восстановлены по техническому контексту: test.wmx, calc.exe, LNK, MHT/MHTML, VSTO, XBAP, XAML, Application.
- В блоке про .NET фраза «domain.explore» не восстановлена уверенно.
- В блоке drag-and-drop неясны точные названия части расширений/целей: «MyDocs», «Desktop.ini» и «DeskLink» восстановлены по смыслу, но могут отличаться от показанного на слайде.
- Вопросы из зала в конце почти полностью неразборчивы; сохранен только понятный смысл ответа спикера про Excel-файл как способ доставки и WebBrowser Control в desktop-приложениях.