В январе 1997 года под ярким светом юпитеров телевизионной студии Mitteldeutscher Rundfunk три немецких хакера провели эффектную демонстрацию мобильного кода и порождаемого им хаоса. Вначале они показали страницу Web с приманкой: «Нажми на ссылку, и ты станешь миллионером через пять минут». Затем демонстратор (выступающий в роли пользователя) щелкнул по ссылке и тем самым непреднамеренно инициировал загрузку элементов управления ActiveX. При последующем открытии Quicken фоновая задача тайно инициировала электронный перевод средств на счет «плохого парня».

Этот конкретный хак под названием «Компьютерный клуб «Хаос» так и не стал реальной угрозой. Продемонстрированные элементы управления ActiveX так никогда и не вышли за пределы студии, программа же Quicken была впоследствии изменена для укрепления ее защиты. Однако об этой истории следует помнить, как о предупреждении о разрушительном потенциале мобильного кода.

«Большинство встречающихся примеров вредоносных мобильных кодов представляет не большую опасность, чем хватание за лодыжки, потому что в мире не так много людей, способных сделать нечто большее, — считает Гэри МакГроу, ведущий исследователь Reliable Software Technologies. — Тем не менее нам уже приходилось сталкиваться с опасными попытками овладения чужими средствами и с шантажом банков».

«По моему мнению, мобильные коды представляют серьезную опасность как средство промышленного шпионажа, — продолжает он. — Они могут использоваться для перехвата личных ключей или кодов защиты».

В своей книге под названием «Защита Java» (Gary McGraw and Edward Felten, Securing Java, Wiley, 1999, Second Edition) МакГроу определяет четыре группы риска в нисходящем порядке с точки зрения их опасности:

Некоторые из наиболее изощренных коммерческих серверов Web можно квалифицировать как демонстративные атаки сами по себе, по крайней мере, для тех, кто обращается к ним по медленным коммутируемым соединениям. Атаки с модификацией системы встречаются редко, но мобильный код доказал свою пригодность для этих целей (в лаборатории, не в жизни). Например, элемент управления ActiveX под названием Exploder может закрыть клиента Windows без сохранения данных сразу после щелчка пользователя по ссылке.

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

С ростом популярности приложений общего назначения, таких, как VisiCalc и WordStar, пользователи постепенно привыкли доверять готовому программному обеспечению. (Иногда их доверие оправдывалось, иногда нет.) Высокая стоимость коммерческого программного обеспечения (так, в 1980 году текстовый процессор CP/M стоил 800 долларов) способствовала появлению модели параллельного распространения: пользователи обменивались условно-бесплатным или даже пиратским программным обеспечением с помощью скопированных дисков, интерактивных досок объявлений и узлов ftp. Вскоре это привело к распространению вирусов через исполняемые файлы и загрузочные сектора.

Таким образом, в широком смысле определение «мобильный код» может относиться к любому коду, перемещаемому с одного компьютера на другой, даже если это делается вручную. Это общее определение включает и программы по типу «троянских коней», в частности WormExplore.zip, о которых вы наверняка много слышали в последнее время. В узком смысле, мобильный код — это код, доставляемый на компьютер по сетевому соединению и затем выполняемый автоматически, без вмешательства пользователя.

При всей своей полезности автоматическое выполнение мобильного кода чрезвычайно опасно с точки зрения защиты. Вирусы распространяются посредством присоединения к определенным файлам и ждут своего часа, пока пользователь их не запустит. Последствия могут проявиться далеко не сразу. Враждебный мобильный код («вандал», если воспользоваться термином, введенным в оборот компанией Aladdin Knowledge Systems) обычно тут же ретируется. Вирус просто отравляет ваш колодец, в то время как вандал, образно говоря, стоит за окнами вашей кухни и бросает в них камень за камнем.

Оказавшийся в браузере в результате загрузки страницы Web мобильный код может поступить в виде текста, интерпретация которого должна производиться во время выполнения. Основными примерами такого кода являются JavaScript, Jscript, VPScript и Visual Basic for Applications (макросы Word и Excel).

Java и ActiveX, которым посвящена эта статья, отличаются тем, что браузеру передается уже скомпилированный код (из-за чего контроль за ними оказывается существенно затруднен). В случае Java код компилируется в промежуточный, не зависящий от архитектуры формат — в так называемый байт-код — и выполняется виртуальной машиной Java (Java Virtual Machine, JVM). В случае ActiveX код компилируется в двоичный код для 32-разрядных систем Windows и по сути ничем не отличается от любой динамически компонуемой библиотеки (Dynamic Link Library, DLL), поставляемой с ОС изначально.

Различные виды мобильного кода могут взаимодействовать друг с другом в браузере, что еще больше увеличивает угрозу для защиты, которую каждый из них несет сам по себе. Предположим, например, что компания пытается предотвратить попадание Java в свою сеть, для чего ею взят под контроль порт 80, и тег <APPLET> блокируется всякий раз при его обнаружении. Однако, оказавшись с внутренней стороны брандмауэра, враждебный JavaScript может обойти это ограничение с помощью динамически создаваемого тега.

Технология JavaScript (с Java у них общее только имя) обычно не несет какого-либо риска. Иногда она используется для демонстративных атак с открытием нежелательных окон и перенаправлением браузера с одной страницы на другую. По большому счету, ее применение безвредно, так что отключать JavaScript не имеет смысла (хотя браузеры и предлагают такую возможность).

Java — единственная технология для мобильного кода, с самого начала создававшаяся в расчете на обеспечение безопасного выполнения. При всем своем несовершенстве (это одна из основных мыслей книги Фелтена и МакГроу «Защита Java»), на сегодняшний день Java обеспечивает наилучший баланс между выполнением программы и защитой компьютера. В этом контексте то, что она еще и переносима с одной платформы на другую, — всего лишь дополнительный бонус.

Шумиха вокруг Java позволяет надеяться, что, по крайней мере, в общих чертах читатели уже знают, как эта технология работает. В двух словах, для выполнения мобильного кода Java реализует модель «ящика с песком». Не заслуживающий доверия мобильный код выполняется внутри «ящика с песком» и не имеет права на выполнение множества операций, в том числе на чтение/запись/удаление файлов, прослушивание или открытие сетевых соединений и т. д.

При загрузке страницы со ссылкой на апплет Java браузер Web получает байт-код Java от сервера Web. Этот код передается компоненту Java, известному как контролер или верификатор байт-кода. Контролер проверяет правильность формата байт-кода, возможность переполнения или незаполнения внутренних стеков и т. д. Второй компонент, загрузчик классов, определяет, как и когда апплет добавляет код в среду выполнения Java, чтобы апплеты не подменили важные системные компоненты. (Всякая программа Java состоит из одного или более классов, совокупности информационных объектов и методов манипулирования ими.)

Наконец, третьим компонентом является менеджер защиты, обращение к которому происходит всякий раз, когда кто-либо пытается выполнить потенциально опасные действия (например, файловую операцию). Менеджер защиты принимает решения с учетом того, откуда поступил запрашивающий класс. Так, встроенные классы имеют большие привилегии, нежели классы, загруженные по сети. (По этой причине классы неизвестного происхождения лучше не помещать в CLASSPATH, так как в результате они будут рассматриваться как встроенные.)

Вместе контролер байт-кода, загрузчик классов и менеджеры защиты обеспечивают чрезвычайно эффективное решение. Однако ошибка при программировании любого из них может нарушить всю стройную систему защиты. Именно поэтому в прессе иногда появляются сообщения об атаках на виртуальные машины конкретных производителей. В этом случае мы имеем дело со взломом не модели защиты Java, а одной конкретной реализации данной модели.

Чтобы стать действительно полезными, мобильные программы Java должны покинуть свою «песочницу». Другими словами, из «приложеньиц» они должны превратиться в приложения. Сделать это позволяет Java Development Kit (JDK) 1.1, куда включены API для шифрования и поддержка цифровых сертификатов. Апплеты из архива Java (файл *.JAR) могут быть подписаны, в результате конечный пользователь получает уверенность, что они поступили от известного источника и не были изменены. Если пользователи получат код апплета, подписанный кем-то, кому они доверяют, то они могут дать команду браузерам и JVM рассматривать этот код как локальный.

Java 1.2 (позднее переименованный в Java 2) идет еще дальше (см. статью «Мобильный код: обращаться осторожно!» в этом номере LAN). Отказываясь от защиты по принципу «все или ничего», он вводит более детализированную модель, в соответствии с которой любой код — локальный; загруженный, но заслуживающий доверия; не пользующийся доверием — получает только те привилегии, которые ему необходимы для выполнения его задачи. Другими словами, «ящик с песком» остается, но он может принимать разные размеры и формы.

Например, только определенный код может иметь право доступа к файловой системе, только определенный код может иметь право доступа к сети, только определенный код может иметь право доступа к графическим ресурсам, таким, как окна, и т. д. Помимо этих функций Java 2 имеет также компоненты, с помощью которых разработчики могут создавать полнофункциональный графический пользовательский интерфейс.

Суммируя сказанное, можно утверждать: пробелы в защите Java — явление чрезвычайно редкое, и реальные атаки проводились только в лабораторных условиях при поиске слабостей конкретных JVM (см. врезку «Клуб «Ошибка месяца»). Не получивший пока широкого распространения Java 2 смещает акценты в компромиссе между безопасностью и функциональностью. По словам Гэри МакГроу, «это наилучший подход, но он нуждается в доработке».

Java превратилась из среды выполнения мобильного кода с чрезвычайно жесткими ограничениями сначала в среду по принципу доверия с правами «все или ничего», а затем в более детализированную систему привилегий, вопросы управления которой еще не до конца решены. Хорошо это или плохо, но ActiveX застрял на втором этапе эволюции.

При обращении ActiveX-совместимого браузера, такого, как Internet Explorer (IE), к странице, содержащей код ActiveX, вначале он загружает код, а затем просматривает его в поисках подписи, создаваемой с помощью технологии Authenticode компании Microsoft. Authenticode позволяет физически вставлять подписи в существующие форматы файлов (*.EXE, *.CAB, файлы классов и т. д.) вместо того, чтобы передавать их внешним образом. Используя цифровые сертификаты, выдаваемые VeriSign, браузер может с помощью подписи проверить, что код не подвергался изменениям.

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

К сожалению, после попадания на клиентский компьютер ActiveX может делать все то же, что и другие программы Windows: например, выполнять программы, отправлять электронную почту, удалять файлы и т. д. Доверившись создателю программы, пользователь, по сути, соглашается на кота в мешке, после чего у него нет пути назад.

Демонстрация трюка с Quicken, о котором рассказывалось в начале статьи, вызвала дискуссию на Usenet-форуме comp.risks. Боб Аткинсон, главный архитектор технологии Authenticode, заявил, что подобное не может произойти на практике, потому что пользователь никогда не даст разрешения на выполнение неподписанного элемента управления ActiveX. Если же элемент управления будет подписан, то «мошенники оставят четкие ясные отпечатки всюду на своем незаконном творении».

Эдвард Фелтен, в отдельном сообщении (см.http://kimera.cs.washington.edu/activex/felten.txt), высказывает мысль, что опасность может возникнуть из-за компрометации личных ключей автора или в результате успешной модификации подписи. Или, учитывая то, что Authenticode предлагает пользователю доверять данному автору и впредь, мошенник может написать серию невинных элементов управления ActiveX для создания положительного имиджа, а затем подсунуть враждебный или разрушительный код.

Если атака удастся, то определить, какой именно элемент управления ActiveX и автор ответственны за нее, будет непросто. Может оказаться, что осуществивший атаку элемент попал в систему давным-давно и был запрограммирован на активизацию в конкретный момент. «Доказательства, реальные или мнимые, не выдержат первой же перекрестной проверки, — пишет Фелтен. — Цифровые подписи могут обеспечить учет, но только в случае более жесткого протоколирования и аудита, чем имеющиеся в современном потребительском программном обеспечении».

Другая проблема в том, что инфраструктура PKI находится пока в зачаточном состоянии, и соответствующие стандарты не получили еще широкого распространения.

Главный недостаток ActiveX (и Java 2) в том, что он возлагает на пользователя принятие решений, касающихся защиты. «Если диалоговое окно предложит выбор между танцующими поросятами и защитой, — говорит Эдвард Фелтен, — то многие пользователи предпочтут танцующих поросят».

Несмотря на то что подавляющее большинство пользователей сегодня не сталкивается с какими-либо проблемами при использовании ActiveX и Java, эти технологии представляют определенную угрозу с точки зрения безопасности системы. Что же делать?

Одной из крайностей является подход «будь что будет»: «Если пользователи хотят угробить свои машины, загружая всякие услады для глаз, то это их дело». Однако, как говорит МакГроу, «те, кто думает, что реальные хаки представляют собой летящие флаги, вызывающие крах браузера, чрезвычайно наивны. Действительная опасность исходит от тех, которые действуют украдкой, открывают порты для подслушивания и остаются незаметны».

Другая крайность состоит в полном блокировании Java и ActiveX. В некоторых компаниях это, возможно, оправданно, но для большинства — это выплескивание младенца вместе с водой. Так, Microsoft использует ActiveX для предоставления обновлений и исправлений Windows, в частности, чтобы клиенты могли получить последние заплаты системы защиты.

Таким образом, для большинства людей наиболее здравый подход состоит в настройке браузера на отказ всем неподписанным кодам. (Более подробно о конфигурации браузера можно прочитать в статье «Мобильный код: обращаться осторожно!» этого номера LAN.) Кроме того, защиту можно укрепить с помощью независимого программного обеспечения. Первоначально подобные программы предлагались отдельно компаниями, специализирующимися в области защиты мобильного кода, такими, как Aladdin Knowledge Systems, Finjan и Security-7 (в настоящее время входит в состав Computer Associates). Теперь защита от вандалов интегрирована в программные антивирусные пакеты.

Такое программное обеспечение выполняет две функции: во-первых, оно пытается идентифицировать мобильный код при его поступлении из Internet в локальную сеть (а также, возможно, при его отправке из локальной сети в Internet). Как отмечалось ранее, эта задача может оказаться сложнее, чем просто поиск определенных тегов, — в особенности если мобильный код поступает через Secure Sockets Layer (SSL) или по другим шифруемым каналам. После идентификации мобильный код проверяется по базе данных на предмет принадлежности к известным образцам вредоносного кода.

Во-вторых, оно дополняет имеющийся у браузера «ящик с песком» (отсутствующий в случае ActiveX). Это делается посредством выполнения мобильного кода на сервере до передачи его клиенту или за счет обеспечения дополнительной защиты при выполнении кода на клиенте. Из-за сложности идентификации и перехвата мобильного кода некоторые виды защиты на клиенте придется, по-видимому, использовать в любом случае.

Браузеры должны иметь гораздо лучшие механизмы обеспечения защиты — от управления «плюшками» и закладками до фильтрации информационного наполнения и «ящиков с песком» для JavaScript/Java/ActiveX, чтобы пользователям не надо было приобретать специальное программное обеспечение в этих целях. Однако даже если браузеры будут исправлены в нужном духе, то, по-видимому, без дополнительного программного обеспечения защиты все равно не удастся обойтись, так как вряд ли кто-нибудь хочет столкнуться с непредвиденными неприятностями. Удачи!

Джонатан Эйнджел — старший редактор Network Magazine. С ним можно связаться по адресу: jangel@mfi.com.

Насколько опасны пробелы в защите от мобильного кода? К сожалению, кратко на этот вопрос ответить нельзя. Однако не будет преувеличением сказать, что каждый месяц кто-нибудь из числа специально занимающихся отловом ошибок обнаруживает очередной изъян. Этим, в частности, занимается Secure Internet Programming Team из Принстона (http://www.cs.princeton.edu/sip/history/index.php3/), чье название может звучать как оксюморон, во всяком случае пока; Карстен Сор, аспирант из Марбургского университета, Германия (http://www.uni-marburg.de/); испанский консультант Хуан Картанго (http://pages.whowhere.com/computers/cuartangojc/index.html); Георгий Гунинский из Болгарии (http://www.nat.bg/~joro/) и многие другие.

В октябре 1999 года, например, Сор сообщил об изъяне контролера байт-кода в виртуальной машине Java компании Microsoft. Возможность скрытого нарушения правил типов Java открывала перед вредоносным апплетом путь для чтения конфиденциальных данных, изменения или удаления файлов и слежения за действиями пользователя. Этот изъян был ликвидирован 25 октября, как раз когда данная статья готовилась к печати.

За месяц до этого Microsoft пришлось искоренять еще один изъян, на этот раз в двух разных стандартных элементах управления ActiveX (scriptlet.typelib и Eyedog), который компания ошибочно маркировала как «safe for scripting». Вследствие этого браузер Internet Explorer (IE) мог, по указанию враждебной страницы Web, создавать или изменять файлы. Кроме того, он позволял собирать и передавать информацию из реестра.

А за какие-то несколько дней до того компания объявила об еще одном уязвимом месте JVM — вследствие этой ошибки апплету Java мог функционировать вне «ящика с песком». Такой апплет, как подчеркивалось в бюллетене защиты Microsoft, мог «предпринять любые действия в отношении компьютера пользователя».

Еще более усложняет ситуацию для пользователей Windows то, что Microsoft JVM поставляется не только с IE, но и с другими продуктами (Visual Studio, например). Что касается элементов управления ActiveX, то они часто устанавливаются не только со страниц Web, но и с дистрибутивов программного обеспечения независимых разработчи-ков. Вместе с тем очень часто пользователи не имеют ни малейшего представления о том, какие элементы управления находятся на их компьютерах или какую JVM они используют. Определить, какая Microsoft JVM установлена на вашей машине, можно с помощью команды JVIEW, как описывается в http://www.microsoft.com/security/bulletins/ms99-031faq.asp/. Узнать, как удалить элементы управления ActiveX, можно на http://support.microsoft.com/support/kb/articles/q154/8/50.asp.

Netscape Navigator и другие браузеры не работают с ActiveX — по крайней мере, без помощи подключаемых модулей, таких, как ScriptActive (от Ncompass Labs), — и поэтому несколько безопаснее IE. Однако проблемы есть не только у Microsoft. В апреле 1999 г. Карстен Сор обнаружил серьезный изъян в защите виртуальной машины Java, поставляемой Sun Microsystems и Netscape. За прошедшее с тех пор время он был, естественно, исправлен, но глупо ожидать, что больше никаких ошибок не осталось.

Несмотря на то что концептуально Java представляет собой наиболее надежную систему предоставления мобильного кода, огромное изобилие клиентов — от телевизионных приставок до интеллектуальных телефонов и смарт-карт — требует разработки новых JVM. А так как ни один программист не совершенен, то и реализации Java не совершенны, так что нам остается только ждать обнаружения новых дыр.

Ответы Линкольна Штайна на часто задаваемые вопросы по защите World Wide Web написаны ясным языком, они вполне исчерпывающие и регулярно обновляются. Ответы размещены на нескольких зеркалах, основная же копия находится на http://www.w3.org/Security/Faq/.

«Энциклопедия вирусов» на базе HTML содержит описание свыше 15 000 вирусов, рецепты по их лечению и снимки экранов инфицированных систем. Ее можно загрузить с http://www.kasperskylab.ru/eng/products/eval.html.

Chaos Computer Club документировал свой трюк с ActiveX вместе со снимками экранов Quicken на http://www.iks-jena.de/mitarb/lutz/security/activex.en.html.

Security Internet Computing Team из Принстонского университета предлагает сравнение Java и ActiveX на http://www.cs.princeton.edu/sip/java-vs-activex.html. Ответы на вопросы по защите Java можно найти на http://www.cs.princeton.edu/sip/faq/java-faq.php3/. Кроме того, она предлагает образец приложения Java Filter, с помощью которого пользователи могут задать, с каких URL они согласны получать апплеты, а с каких — нет; см. http://www.cs.princeton.edu/sip/JavaFilter.

Дэвид Хопвуд предлагает еще одно любопытное сравнение защиты Java и ActiveX на http://www.users.zetnet.co.uk/hopwood/papers/compsec97.html.

Книга Securing Java, by Gary McGraw and Edward Felten, Wiley, 1999, Second Edition посвящена преимущественно технологии Java, но ее следует прочитать всем, кого волнует защита мобильных кодов. Приводимый в книге список ссылок можно найти на Web-сервере авторов http://www.securingjava.com/references/. Среди других полезных книг можно назвать The Web Security Sourcebook, by Aviel Rubin et al., Wiley 1997 и Securing Internet Commerce, by Anup Ghosh, Wiley, 1998.

Демонстрацию для Web декомпилятора Java компании Ahpah Software можно посмотреть на http://www.ahpah.com/cgi-bin/suid/~pah/demo.cgi/.

Тем, чьи компьютеры способны интерпретировать PostScript, будет интересно прочитать статью «Блокирование апплетов Java на брандмауэре», написанную Д. Мартином, С. Раджагопаланом и А. Рубином. См. http://www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z/.

Гизли Ханнемир описывает «троянских коней» на базе PostScript и Adobe Acrobat на http://home.sol.no/~gisle/trap.html.

Наконец, Common Content Inspection (CCI) API представляет собой спецификацию, с помощью которой брандмауэры и продукты для блокирования информационного наполнения (антивирусные программы, фильтры и т. д.) могут взаимодействовать друг с другом и обмениваться между собой информацией. Она опирается на более ранний Content Vectoring Protocol (CVP), разработанный Check Point Software Technologies (http://www.checkpoint.com) и поддерживаемый многими независимыми разработчиками. Общую информацию о нем можно найти на http://www.stardust.com/cci/.