Ранее мы уже писали об обнаруженной уязвимости нулевого дня в Internet Explorer, которая позволяет при помощи специально подготовленного MHT-файла загрузить информацию с компьютера пользователя на удалённый сервер. Недавно данную уязвимость, обнаруженную специалистом по безопасности Джоном Пейджем, решил проверить и изучить другой известный специалист в данной области — Митя Колсек, директор компании ACROS Security, занимающейся аудитом безопасности, и со-основатель сервиса микропатчей 0patch. Он опубликовал полную хронику своего расследования, указав на то, что Microsoft значительно недооценила серьезность проблемы.
Изображение из блога компании Мити Колсека в жизнерадостных тонах сообщает о неисправленной и непризнанной уязвимости нулевого дня в Internet Explorer, и о том, что у них уже есть готовый микропатч, решающий эту проблему
Как ни странно, вначале Колсек не смог воспроизвести описанную и продемонстрированную Джоном атаку, когда он использовал Internet Explorer, работающий в Windows 7, чтобы загрузить, а затем и открыть вредоносный MHT-файл. Хотя его менеджер процессов показал, что system.ini, который планировалось похитить у самого себя, был прочитан спрятанным в MHT-файле скриптом, но не был отправлен на удалённый сервер.
«Это выглядело как классическая ситуация работы так называемой «метки для файла, полученного из сети (англ. mark-of-the-Web)», — пишет Колсек. «Когда файл получен из Интернета, правильно работающие приложения Windows, такие как веб-браузеры и почтовые клиенты, добавляют метку к такому файлу в форме альтернативного потока данных с именем Zone.Identifier, содержащего строку ZoneId = 3. Это позволяет другим приложениям узнать, что файл получен из ненадёжного источника и, следовательно, должен быть открыт в песочнице или в другой ограниченной среде».
Исследователь убедился в том, что IE действительно поставил такую метку для загруженного MHT-файла. Затем Колсек попытался загрузить этот же файл с помощью Edge и открыть его в IE, который остаётся приложением по умолчанию для файлов MHT. Неожиданно эксплойт сработал.
Edge помимо идентификатора безопасности файла также добавляет информацию, откуда файл был загружен
Вначале исследователь проверил «mark-of-the-Web», оказалось, что Edge сохраняет в альтернативном потоке данных помимо идентификатора безопасности ещё и источник происхождения файла, что может вызвать некоторые вопросы по отношению к приватности такого метода. Колсек предположил, что дополнительные строки могли запутать IE и не дать ему прочитать идентификатор безопасности, но, как оказалось, проблема была совсем в другом месте. После длительного анализа специалист по безопасности нашел причину в двух записях в списке контроля доступа, добавляющих некой системной службе право на чтение MHT-файла, которые внёс туда Edge после его загрузки.
Две первые строчки в правах доступа Edge добавил к скачанному MHT-файлу. Первая строчка привела к сбою системы безопасности Internet Explorer
Джеймс Форешоу (James Foreshaw) из специальной команды по поиску уязвимостей нулевого дня — Google Project Zero — подсказал в своём твиттере, что добавленные Edge записи относятся к групповым идентификаторам безопасности для пакета Microsoft.MicrosoftEdge_8wekyb3d8bbwe. После удаления второй строчки SID S-1-15-2 — * из списка контроля доступа вредоносного файла эксплойт больше не работал. В итоге каким-то образом разрешение, добавляемое Edge, позволяло файлу обходить песочницу в IE. Как предположил Колсек с коллегами, данные разрешения Edge использует для защиты скачанных файлов от доступа к ним процессов с низким уровнем доверия, запуская файл в частично изолированной среде.
Дальнейшее исследование показало, что изменение в правах доступа вызывает отказ для каких-то команд Internet Explorer, которые он пытается выполнить перед открытием MHT-файла
Дальше исследователь захотел лучше понять, что же вызывает сбой системы безопасности IE. Углублённый анализ с использованием утилиты Process Monitor и дизассемблера IDA в конечном итоге показал, что установленное Edge разрешение не позволило функции Win Api GetZoneFromAlternateDataStreamEx прочитать поток файла Zone.Identifier и вернуло ошибку. Для Internet Explorer такая ошибка при запросе метки безопасности файла оказалась совершенно неожиданной, и, по всей видимости, браузер счёл, что ошибка равнозначна тому, что файл не имеет метки «mark-of-the-Web», что автоматически делает его доверенным, после чего IE разрешил спрятанному в MHT-файле скрипту выполнение и отправку целевого локального файла на удаленный сервер.
Как выяснилось, далее отказ затронул функцию «GetZoneFromAlternateDataStreamEx», которая должна была сообщить IE, что файл получен из небезопасного источника
«Вы видите здесь иронию?» — спрашивает Колсек. «Незадокументированная функция безопасности, используемая Edge, нейтрализовала существующую, несомненно, гораздо более важную функцию (mark-of-the-Web) в Internet Explorer».
Несмотря на возросшую значимость уязвимости, позволяющую запускать зловредный скрипт как доверенный, нет никаких признаков того, что Microsoft намерена исправить ошибку в ближайшее время, если она вообще будет когда-либо исправлена. Поэтому мы всё еще рекомендуем вам, как и в прошлой статье, изменить программу по-умолчанию для открытия MHT-файлов на любой современный браузер.
Конечно, исследование Колсека не осталось и без небольшого самопиара. В конце статьи он продемонстрировал небольшой написанный на ассемблере патч, который может использовать сервис 0patch, разрабатываемый его компанией. 0patch автоматически обнаруживает уязвимое ПО на компьютере пользователя и применяет к нему небольшие исправления буквально на лету. Например, в описанном нами случае, 0patch заменит сообщение об ошибке в функции GetZoneFromAlternateDataStreamEx на значение, соответствующее недоверенному файлу, полученному из сети, благодаря чему IE не позволит выполнить какие-либо спрятанные скрипты в соответствии со встроенной политикой безопасности.
Если вы заметили ошибку — выделите ее мышью и нажмите CTRL+ENTER.
материал сайта 3dnews.ru
