Захист від мобільного коду

Джонатан Ейнджел, Журнал мережевих рішень «LAN»

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

Джонатан Ейнджел – Старший редактор 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 не досконалі, так що нам залишається тільки чекати виявлення нових дірок.

Ресурси Internet

Відповіді Лінкольна Штайна на часті запитання по захисту 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/.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*