Cross Domain Scripting

Введение.

Идея написать эту статью мне пришла в голову после того, как понадобилось дать одному новичку ссылку на подробное и понятное объяснение этого термина. Полазив по поисковикам, я с удивлением обнаружил, что найти такую статью достаточно непросто. Термин либо не объяснялся вообще, либо в двух словах и по-английски:). Между тем в Windows уязвимости такого типа обнаруживаются довольно часто и они более чем серьёзны! Поэтому в этой статье я попытался как можно подробнее и понятнее описать этот тип атак, особенности эксплуатации данного типа уязвимостей и защиты от них, привести конкретные примеры. Статья писалась в основном, конечно, для новичков, но, надеюсь, будет чем-то полезна и для более опытных читателей.

Что такое Cross Domain Scripting?

Изначально Cross-Domain Scripting (CDS) был связан с недостатками в модели безопасности всем известного «ослика» aka Internet Explorer (IE). Однако, т.к. архитектурные особенности современных браузеров не сильно отличаются друг от друга, то атакам данного типа в настоящее время подвержены практически все известные веб-браузеры. Тем не менее, существующие отличия между программами этого класса приводят к тому, что чаще всего найденный CDS является «браузерозависимым», т.е., например, работает на IE, но не работает на Opera или наоборот.
В основе уязвимостей типа CDS лежит понятие «домена». В данном контексте смысл этого понятия несколько отличается от общепринятого. «Домен» - это уже не просто адрес сайта в Интернете, и даже не «область пространства иерархических имен сети Интернет», - данное понятие обозначает некоторую «границу безопасности» (security boundary), выходить за которую не разрешено ни одному пользовательскому скрипту.
В основе модели безопасности любого веб-браузера лежит тот принцип, что ресурсы различных доменов (странички, скрипты и т.д.) не могут никоим образом пересекаться друг с другом, т.е. получать доступ к внутреннему содержимому и данным друг друга. Если бы это было возможно, то, например, скрипт на домашней страничке юного хакера Васи мог бы получить доступ к данным почтового ящика на Mail.Ru ничего не подозревающего пользователя, которого Вася заманил на свою страничку. Вот было бы веселье:)! Более того, согласно архитектуре Windows и концепциям построения современных браузеров, любой сетевой ресурс в локальной сети и собственная файловая система клиента это тоже «домены», а значит к ним возможно обращение из скриптов точно так же, как к любому ресурсу в Интернете! Собственно именно локальная файловая система клиента и является чаще всего целью cross-domain атак.
В тоже время взаимодействие между собой ресурсов (страничек и скриптов) внутри домена (и всех его субдоменов!) концепцией безопасности Microsoft разрешено и в принципе никак не ограничено. Трудно судить правильно это или нет, но то, что так проще:) и при этом расширяются возможности веб-серфинга, - это точно.
Так что же такое Cross-Domain Scripting? В контексте всего вышесказанного этот термин можно перевести как – «междоменный скриптинг», т.е. «пересечение скриптом границ домена» - нарушение той заветной линии безопасности, выход за которую дает доступ к данным других доменов, в том числе к локальной файловой системе клиента. Такое нарушение чаще всего сопровождается возможностью записывать и выполнять произвольный HTML и Java код в контексте других доменов, читать данные других доменов (например, формы с паролями или файлы на системе клиента) и даже выполнять произвольные команды на удаленном компьютере.
Часто понятие «cross-domain scripting» подменяют понятием «cross site scripting» (XSS). Действительно, зачастую бывает, что внешние проявления этих уязвимостей очень похожи, - особенно, когда в результате CDS происходит вставка Java-кода в контекст другого домена. Однако, несмотря на сходство, суть этих уязвимостей различна:
Во-первых, область действия XSS по определению ограничена одним доменом. В то время, как CDS в общем случае подвержены все домены + локальная файловая система клиента.
Во-вторых, причина XSS уязвимостей кроется в ошибках скриптов, расположенных на сервере, и, как правило, заключается в недостаточной фильтрации данных, полученных от пользователя. Источник CDS уязвимостей – клиентское программное обеспечение (браузер и операционная система), и он обычно никак не связан с пользовательскими данными.
Ну и не надо забывать, что уровень опасности от успешной эксплуатации злоумышленником XSS намного ниже, чем от CDS. Ведь в первом случае, как максимум, произойдет утечка конфиденциальных данных пользователя (пароли и т.д.), причем лишь с одного сайта, а при CDS возможно похищение конфиденциальный данных с любых сайтов, а зачастую и исполнение произвольных команд на системе клиента, что позволяет взять над ней полный контроль.

Как это работает?

Так почему же становится возможным данный тип атак? Причина заключается в том, что та самая «линия безопасности» между доменами создается искусственно, что всю работу по предотвращению междоменного скриптинга выполняет веб-браузер и его компоненты – нет архитектурных ограничений. А значит, всегда есть вероятность ошибки в процедурах проверки, возможность их обойти, что в настоящее время с успехом и делается.
За более чем десятилетнюю историю использования веб-браузеров было найдено множество способов преодолеть заветную границу домена. Однако большинство из них можно условно разделить на два класса:
1.Эксплуатация ошибок безопасности в объектно-ориентированной модели браузеров;
2.Использование промежуточного звена для выполнения атаки.
Рассмотрим подробнее данные классы атак.
В основе первого лежит ярко выраженная объектно-ориентированная архитектура современных браузеров и виртуальной машины Java. Действительно, все, что мы видим на экране веб-браузера, это объекты определенных классов с их свойствами, событиями и методами. Используя эту объектно-ориентированную модель и скрипты Java, мы можем обращаться к любому элементу загруженной в браузер странички, читать и записывать в неё данные, открывать новые окна и т.д. Более того, с помощью скриптов возможно частичное управление элементами самого веб-браузера и даже действиями пользователя: перемещение «Вперед»/«Назад» по страничкам, добавление в «Избранное» и т.п.
Однако отдельные окна или элементы странички в веб-браузере могут принадлежать разным доменам, а значит нужно пресекать обращение к ним. Нельзя допустить, чтобы пользовательский скрипт, открыв другой домен в новом окне браузера, имел возможность что-либо записать туда или считать оттуда. Нельзя допустить, чтобы скрипт на страничке с фреймом, куда подгружен ресурс с другого домена, смог обращаться к этому фрейму и получать доступ к его данным. Более того, утечка данных от одного домена к другому возможна не только через свойства, но и через методы и события объектов! Скажем скрипт на страничке юного хакера Васи, куда он заманил ничего не подозревающего пользователя, не должен «знать» какие клавиши тот нажимает, когда вводит пароль для входа в Mail.Ru, открытый в другом окне браузера. Ну и таких примеров можно привести очень много!
К сожалению, а может и к счастью;), такие проверки безопасности зачастую выполняются некорректно, а иногда и отсутствуют вовсе! Поэтому становится возможным обращаться к элементам страничек с других доменов, считывать из них данные, записывать свой Java код в контекст других доменов и т.д. Из-за достаточно сложной архитектуры объектно-ориентированной модели такие «дырки» в ней находятся довольно часто. Ниже приведен пример данного класса атак (Пример 1).
Для выполнения атак второго класса используется некоторое промежуточное звено. Что делать, когда прямое обращение к другому домену запрещено? Правильно! Идти в обход! А вдруг есть кто-то иди что-то, кому это обращение не запрещено, и оно сможет считать оттуда данные и передать нам, или наоборот – записать наши данные в контекст другого домена. Наиболее уязвимой с этой точки зрения оказывается технология ActiveX от Microsoft. Технология ActiveX предоставляет в распоряжение пользователя объекты, их свойства и методы, которые используются операционной системой для каких-либо вспомогательных целей. Например, для просмотра через веб-браузер файлов справки Windows (*.chm) используется HTML Help ActiveX компонент. Не правда ли удобно? Однако зачастую объекты ActiveX выполняют роль своего рода «троянских коней»! Дело в том, что существует способ управлять этими компонентами (загружать, обращаться к их свойствам и методам) через веб-страничку. Для этого используется тег . А ведь зачастую эти ActiveX объекты содержат методы манипуляций с файловой системой, запуска приложений, навигации по веб-страницам и т.д. Т.о. появляется возможность извне производить все эти действия и более того осуществлять полноценный обмен данными с жертвой! Например, читать содержимое локальных файлов клиента и отправлять обратно скрипту эти данные, или с помощью ActiveX объекта открывать другой домен и записывать в его контекст свой Java код. Именно с помощью данного класса атак иногда удается добиться выполнения произвольного кода (запуска cmd.exe с нужными параметрами) на системе клиента. В настоящее время данный тип CDS также широко распространен и постоянно находят новые уязвимые ActiveX объекты. Ниже приведен пример такой уязвимости (Пример 2).
Кроме рассмотренных классов CDS существуют и другие способы обхода междоменных ограничений. Правда, зачастую эти способы являются весьма экзотическими и встречаются нечасто. Например, обнаруженная в июле 2004 года Cross-Cookie уязвимость (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Она позволяла при определенных условиях получать доступ (читать/записывать) к кукам других доменов. Причем это был один из немногих случаев, когда уязвимыми оказались многие браузеры: IE, Mozilla, Opera, Konqueror.
Т.о. CDS является в настоящее время очень распространенным типом атак и постоянно обнаруживаются новые способы эксплуатации этих уязвимостей («вектора атак»).

Примеры CDS

Чтобы все описанное выше было понятней – рассмотрим пару примеров реальных CDS уязвимостей. Все они были найдены в Internet Explorer и позволяют вставлять свой Java код в контекст других доменов. Обычно это используется для хищения кукисов или выполнения произвольных действий в рамках текущей сессии пользователя.

Пример 1. Similar Method Name Redirection Cross Domain Vulnerability – CAN-2004-0727 (MS04-038)

Эта уязвимость была обнаружена в июле 2004 года и связана ошибкой безопасности в объектно-ориентированной модели IE (1-ый класс CDS уязвимостей из рассмотренных выше).
Суть её в следующем. Как известно, чтобы загрузить в текущее окно браузера другую страницу (возможно из другого домена), можно использовать свойство location.href или метод location.assign(). Однако, после загрузки требуемой страницы дальнейшее исполнение Java кода текущего скрипта невозможно – иначе скрипт мог бы подгрузить Mail.Ru и выполнить в контексте этого домена произвольные действия. Однако оказалось возможным обойти это ограничение путем редиректа (перенаправления) метода location.assign() на точно такой же, но другого окна (ведь у нас объектно-ориентированная модель и мы можем присваивать методы различных объектов друг другу). В результате появилась возможность исполнять Java код в контексте текущего окна, но уже после загрузки требуемой странички – что и требовалось! Следующий скрипт выполняет требуемые действия:


w=window.open("jаvascript:setInterval(function(){try{x=opener.location.href;}catch(e){location.assign('jаvascript:alert(document.cookie)');window.close();}},100)");
w.location.assign=location.assign;
location.href="/click?http://localhost";


Вначале открывается новое окно, которое в цикле ждет загрузки странички (в нашем случае с localhost) в главное(текущее) окно. Тем временем скрипт переназначает методы location.assign() и начинает загрузку в главное окно требуемой страницы (localhost). Как только загрузка заканчивается, в цикле нового окна срабатывает триггер, методом assign() вставляется Jаva код (из-за переназначения методов вставка происходит в контекст главного окна) и новое окно тут же закрывается. В результате выполнения скрипта в контексте localhost исполняется dоcument.cookie.
Видимо разработчики Microsoft не предусмотрели возможность редиректа функций и не вставили проверку безопасности (или вставили некорректно) в данное событие. Для эксплуатации данной уязвимости необходимо, чтобы в браузере был разрешен Active scripting. Почитать подробнее об этой уязвимости и найти рабочий пример эксплойта вы можете здесь: http://greyhatsecurity.org/similarmethodnameredir-discussion.htm.

Пример 2. DHTML Editing Component ActiveX Control Cross Domain Vulnerability CAN-2004-1319 (MS05-013)

Данная уязвимость была обнаружена в конце прошлого года, но исправлена лишь в феврале. Она относится ко 2-ому типу CDS атак из рассмотренных выше, т.е. использует промежуточное звено (DHTML ActiveX) для проведения атаки. Для успешной эксплуатации уязвимости необходимо выполнить следующую последовательность действий:
1.Загрузить DHTML ActiveX. Это делается при помощи тега .




2.Загрузить в ActiveX объект нужную нам страницу (произвольный домен). Это делается путем выполнения в контексте DHTML ActiveX нашего скрипта.

exploit.DOM.Sсript.execSсript("window.name="new";open("http://localhost","new");");

3.Ну а после этого уже можно вставлять наш HTML и Java код. Он будет выполняться в контексте загруженного домена. Все просто до безобразия:)!

exploit.DOM.Sсript.execSсript("alert(document.cookie)");

Каковы же причины данной уязвимости? Я бы выделил их две:
Во-первых, возможность извне выполнять произвольные скрипты внутри ActiveX объекта – на мой взгляд, это слишком большая вольность!
Во-вторых, при загрузке страницы в DHTML ActiveX туда загружается ВСЁ – даже кукисы! Вопрос: зачем? Данный ActiveX объект может использоваться для редактирования страниц и зачем там нужны кукисы – непонятно…
Естественно, для эксплуатации этой уязвимости необходимо, чтобы в браузере было разрешено выполнение ActiveX. Почитать подробнее об этой уязвимости и найти рабочий пример эксплойта вы можете здесь: http://greyhatsecurity.org/abusiveparent-discussion.htm.

Как защититься?

Защититься от междоменного скриптинга не так просто. Т.к. варианты эксплуатации («вектора атак») этих уязвимостей очень разнообразны, то большинство мер будут иметь весьма ограниченный и временный характер. Перекрыть все «вектора атак» практически невозможно. Поэтому я дам несколько рекомендаций, которые способны лишь снизить риск успешной атаки, но не защитить полностью.
1.Соблюдение осторожности при веб-серфинге.
Для успешного выполнения почти всех разновидностей CDS необходимо вначале заманить ничего не подозревающего пользователя на страницу-эксплойт, после чего он подвергнется данной атаке. Нельзя доверять ссылкам, как бы невзначай, подкинутым в разговоре, различным «домашним страницам» и т.п. Это наверное главная рекомендация из всех. К сожалению грамотно примененная XSS может перечеркнуть всю осторожность.
2.Оперативная установка заплаток для операционной системы и браузера.
Обычно для всех опубликованных в Интернете уязвимостей производитель (даже Microsoft:)) в короткие сроки выпускает исправление (заплатку). Оно защитит от данной конкретной уязвимости, но не от других, еще не найденныхJ (или найденных, но не приданных огласке). Естественно, рассмотренные в примерах уязвимости уже давно исправлены Microsoft, и кто захотел, тот уже позаботился о своей безопасности.
3.Отключение в браузере ActiveX и Active Scripting.
Эта мера сделает невозможным запуск в бразере ActiveX и выполнение Java или VBS скриптов. Это действительно сделает неэффективными большинство CDS атак, правда может существенно отразиться на функциональности посещаемых сайтов. Однако не всегда CDS для успешной атаки требует поддержки от браузера ActiveX или Active Scripting – и это не панацея от всех бед!
4.Работа в Интернете только с ограниченными правами.
Выполнение этой рекомендации позволит, даже в случае успешной атаки, снизить возможный ущерб от неё. Как известно браузер (а значит и все скрипты в нем) запускается с правами текущего пользователя. Не дайте хакеру Васе получить cmd.exe с правами Администратора:)!
Следование всем этим рекомендациям поможет стать трудноуязвимым для Cross-Domain Scripting!

Дата створення/оновлення: 25.05.2018