Безопасность

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

В январе 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 смещает акценты в компромиссе между безопасностью и функциональностью. По словам Гэри МакГроу, это наилучший подход, но он нуждается в доработке.

ЗАЩИТА ACTIVEX ПРОТИВОРЕЧИЕ В ОПРЕДЕЛЕНИИ?

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, чтобы пользователям не надо было приобретать специальное программное обеспечение в этих целях. Однако даже если браузеры будут исправлены в нужном духе, то, по-видимому, без дополнительного программного обеспечения защиты все равно не удастся обойтись, так как вряд ли кто-нибудь хочет столкнуться с непредвиденными неприятностями. Удачи!