Атака через Internet. 8.4. черв'як

1. 8.4. черв'як
2. 8.4.1. Стратегії, які використовуються вірусом
3. 8.4.1.1. Налагоджувальний режим в програмі Sendmail
4. 8.4.1.2. Помилка в демона Fingerd
5. 8.4.1.3. Віддалене виконання і підбір паролів
6. 8.4.1.4. Віддалений командний інтерпретатор і довірені хости
7. 8.4.2. Маскування дій вірусу
8. 8.4.3. Помилки в коді вірусу
9. 8.4.3.1. Запобігання повторного зараження
10. 8.4.3.2. Використання евристичного підходу для визначення цілей
11. 8.4.3.3. Невикористані можливості вірусу
12. 8.4.4. Докладний аналіз структури і процедур вірусу
13. 8.4.4.1. імена
14. 8.4.4.1.1. Обробка аргументів командного рядка
15. 8.4.4.2. процедура doit
16. 8.4.4.2.1. Ініціалізація процедури doit
17. 8.4.4.2.2. Основний цикл процедури doit
18. 8.4.4.3. Процедури підбору пароля
19. 8.4.4.3.1. фаза 0
20. 8.4.4.3.2 .. Стратегія 1
21. 8.4.4.3.3. стратегія 2
22. 8.4.4.3.4. стратегія 3
23. 8.4.4.4. Процедури пошуку віддалених машин
24. 8.4.4.4.1. Порядок роботи
25. 8.4.4.4.2. Процедура ll.c - "абордажний гак"

8.4. черв'як

У цьому розділі ми перейдемо до докладного розгляду не тільки самого відомого випадку порушення безпеки Мережі, але і самого великого інциденту в області комп'ютерної безпеки взагалі - вірусу Морріса (Internet worm). Більш того, він був не просто одиничне вторгнення в певний комп'ютер, а дав відповідь на давнє запитання, чи можуть не в абстрактних умовах існувати саморепродуцірующіеся програми (те, що теоретично це можливо, визнавалося багатьма). А підтвердивши можливість створення такої програми, цей інцидент дав поштовх до появи цілої галузі комп'ютерної безпеки - комп'ютерної вірусології (на той час вже існували одиничні віруси і на персональних комп'ютерах - саморепродуцірующіеся в межах одного комп'ютера).

До 1988 року інтернет як глобальна мережа вже практично сформувався, і практично всі послуги сьогоднішнього дня (крім WWW) використовувалися і тоді. З іншого боку, в хакерських і околохакерскіх колах накопичилося достатньо інформації про пролом в системах безпеки і способах несанкціонованого проникнення в віддалені комп'ютери. Критична маса була накопичена, і вона не могла не вибухнути.

Отже, на початку листопада 1988 р Мережа була атакована так званим мережевим черв'яком, згодом отримав в російськомовній літературі назву "вірус Морріса" на ім'я його творця - студента Корнельського університету Роберта Морріса-молодшого. Мережевим черв'яком називають різновид комп'ютерних вірусів, що мають здатність до самораспространению в локальної або глобальної комп'ютерної мережі. Для цього черв'як повинен володіти декількома специфічними процедурами:

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

Правові питання і наслідки запуску хробака розглядалися в розділі 1, а тепер ми опишемо детально структуру, механізми і алгоритми, їм приємним. Було вирішено вільно поширювати їх, на відміну від вихідних текстів, отриманих в результаті дизассемблирования. Однак після закінчення 9 років таке обмеження втратило свою актуальність (скористатися сьогодні ними все одно не вдасться), і вони можуть бути знайдені в інтернеті. Більшість матеріалу цього розділу взято з [18, 19].

8.4.1. Стратегії, які використовуються вірусом

Для проникнення в комп'ютери вірус використовував як алгоритми підбору пароля (це детальніше йтиметься в п. 8.4.4), так і "дірки" в різних комунікаційних програмах, які дозволяли йому отримувати доступ без пред'явлення пароля. Розглянемо докладніше ці "дірки".

8.4.1.1. Налагоджувальний режим в програмі Sendmail

Вірус використовував функцію "debug" програми sendmail, яка встановлювала оцінний режим для поточного сеансу зв'язку. Налагоджувальний режим володіє деякими додатковими можливостями, такими як можливість посилати повідомлення, забезпечені програмою-одержувачем, яка запускається на віддаленій машині і здійснює прийом повідомлення. Ця можливість, яка не передбачена протоколом SMTP, використовувалася розробниками для налагодження програми, і в робочій версії була залишена помилково. Таким чином, у наявності типовий приклад атаки за сценарієм 1.

Специфікація програми, яка буде виконуватися при отриманні пошти, міститься в файлі псевдонімів (aliases) програми sendmail або в призначеному для користувача файлі .forward. Ця специфікація використовується програмами, що обробляють або сорти-рующими пошту, і не повинна застосовуватися самою програмою sendmail. У вірусі ця програма-одержувач містила команди, які прибирають заголовки пошти, після чого посилала залишок повідомлення командному інтерпретатору, який створював, компілював і виконував програму на мові Сі, що служила "абордажні гаком", і та, в свою чергу, брала залишилися модулі з атакуючої машини. Ось що передавав вірус через SMTP-з'єднання:

Вірус заражав комп'ютери двох типів - VAX і Sun, тому пересилалися двійкові коди для тієї та іншої архітектури, обидва запускалися, але виконуватися міг тільки один. У комп'ютерах інших архітектур (НЕ VAX і Sun) програми не могли функціонувати, хоча і поглинали системні ресурси в момент компіляції.

8.4.1.2. Помилка в демона Fingerd

Інший недолік, що також відноситься до типовим сценарієм 1, який дозволяв вірусу розповсюджуватися, знаходився в програмі fingerd. Дана програма містила в собі фрагмент коду приблизно наступного вигляду:

Перевірка переповнення буфера в ній не здійснювалася. Так як буфер був в стеці, то переповнення дозволяло створювати в стеці фрагмент коду та змінювати адресу повернення з процедури таким чином, що при поверненні управління передавалося на цей код. Вірус передавав спеціально підготовлену рядок з 536 байт, яка викликала в кінцевому підсумку функцію execve ( "/ bin / sh", 0, 0). Таким способом атакували тільки машини VAX з операційною системою 4.3BSD; на комп'ютерах Sun, що використовують SunOS, такі атаки терпіли невдачу.

8.4.1.3. Віддалене виконання і підбір паролів

Вірус використовував протокол віддаленого виконання програм (rexec), який вимагав для виконання програми на віддаленій машині тільки ім'я користувача і незашифрований пароль. Програма застосовувала для цього імена користувачів локального (атакуючого) хоста, використовуючи той факт, що багато користувачів мають однакові імена і паролі на всіх машинах в мережі. Ця, як і наступна, атака відноситься вже до сценарію 4.

8.4.1.4. Віддалений командний інтерпретатор і довірені хости

Вірус намагався використовувати програму запуску віддаленого інтерпретатора (rsh) для атаки інших машин або з отриманим ім'ям і паролем поточного користувача, або взагалі без аутентифікації, якщо атакують машина довіряє даної. (Файли /etc/hosts.equiv і .rhosts містять список машин, "тих, хто довіряє" даної, т. Е. Доступних для запуску rsh з даної машини.) Він пробував три різних імені для rsh:

Віддалений інтерпретатор за своєю функцією нагадує програму віддаленого виконання, але має більш дружній інтерфейс, так як дистанційно запускається командний інтерпретатор, а не функція exec.

8.4.2. Маскування дій вірусу

Вірус здійснював ряд заходів для приховування своїх дій:

• стирався список аргументів після закінчення їх обробки, тому команда ps не могла показати, яким чином були викликані вірусні програми;
• виконувані файли вірусу після свого запуску негайно знищувалися, і не можна було зрозуміти, звідки з'явився процес. Якщо заражена машина перезавантажувалася в процесі виконання вірусу, то спеціальна програма автоматично відновлювала файл після перезавантаження;
• розмір аварійного дампа встановлювався рівним нулю. Якщо програма аварійно завершувалася, то вона не залишала після себе ніяких слідів. Також відключалися повідомлення про помилки;
• вірус був скомпільований під ім'ям sh, таке ж ім'я використовувалося командним інтерпретатором Bourne Shell, який часто використовується в командних файлах. Навіть старанний адміністратор системи не помічав збільшення числа інтерпретаторів, що функціонують в системі, або не надавав цьому значення;
• вірус розмножувався, гілкуючись на два процесу (роди-тель і нащадок), приблизно кожні три хвилини. Процес-батько після цього завершувався, а процес-нащадок продовжував працювати. Це мало ефект "оновлення" процесу, так як для нового процесу облік використовуваних ресурсів починався з нуля. Крім того, цей захід ускладнювала виявлення вірусу;
• всі текстові рядки, які використовуються вірусом, були закодовані за допомогою операції "виключає або" - XOR 81H. Це, звичайно, слабкий метод, але він дозволив приховати важливі текстові рядки, наприклад, імена відкриваються вірусом файлів.

8.4.3. Помилки в коді вірусу

Вірус містив деяку кількість помилок - від дуже тонких і майже не впливають на його роботу, до грубих і незграбних. Зупинимося на них докладніше.

8.4.3.1. Запобігання повторного зараження

Ділянка коду для запобігання повторного зараження містив багато помилок. Це мало вирішальне значення, т. К. Через те, що багато машин заражалися повторно, навантаження на системи та мережі збільшувалася і ставала вельми відчутною (деякі машини навіть не могли з нею впоратися).

Вірус, "перевіряючий" наявність інших вірусів, намагався зв'язатися з портом 23357 для того, щоб встановити контакт з "таким, що відповідає" вірусом. Якщо це не вдавалося, вірус припускав, що інших вірусів немає, і сам ставав "відповідає".

Якщо зв'язок встановлювалася, "перевіряючий" посилав магічне число 8865431 і протягом 300 секунд очікував іншого магічне число 1345688. Якщо число було невірним, "перевіряючий" розривав зв'язок.

Потім він вибирав випадкове число і посилав "відповідає". Після цього, протягом 10 секунд, він очікував повернення цього числа, після чого складав його з посланим. Якщо сума була парним числом, то "перевіряючий" встановлював значення змінної pleasequit. Інакше кажучи, кожен раз з двох вірусів один "смертник" вибирався випадково.

Після закінчення (успішного або невдалого) сеансу зв'язку "перевіряючий" "засипав" на 5 секунд і намагався стати "відповідальним". Для цього він створював TCP сокет, встановлював його параметри для межпроцессной зв'язку і підключав його до порту 23357.

Цей код містив стільки помилок, що викликає подив той факт, що він взагалі працював. Він завершувався з помилкою при наступних умовах:

• якщо кілька вірусів заражали чисту машину одночасно, то вони так само одночасно намагалися знайти інших в режимі "перевіряючих". Так як ніхто не міг їх знайти, вони поступово переключалися в режим очікування повідомлення і один з них отримував його, а інші припиняли спроби зв'язатися один з одним і не відповідали на запити;
• якщо кілька вірусів одночасно стартували в присутності іншого вже працюючого вірусу, то тільки одному з них вдавалося зв'язатися з активним вірусом, інші не могли цього зробити;
• якщо машина працювала повільно або була сильно завантажена, то це могло привести до вичерпання вірусом ліміту часу, відпущеного на встановлення зв'язку з іншими вірусами, що призводило до припинення обміну.

Зауважимо, що тут вираз "одночасно" має на увазі 5-20 секундний проміжок.

Критична помилка містилася в коді, коли вірус вирішував, що повинен завершитися. Все, що він робив - це встановлював змінну pleasequit. Ця не давало ефекту до тих пір, поки вірус не:

• зібрав список імен машин для їх атаки;
• зібрав список імен користувачів;
• здійснив перебір всіх "очевидних" паролів (див. 8.4.4.3) і не спробував 10 випадково взятих паролів зі свого словника.

Так як вірус видаляв всі тимчасові файли, то його присутність в машині не заважало її повторного зараження.

Багаторазово заражені машини поширювали вірус швидше, можливо пропорційно числу копій вірусу на машині, т. К .:

• вірус перемішував списки імен машин і користувачів, які збирався атакувати, використовуючи генератор випадкових чисел, який залежить від системного часу. Різні копії отримували різні випадкові числа і атакували різні об'єкти;
• вірус проводив багато часу, чекаючи повідомлень від інших вірусів, тому віруси не конфліктували між собою, запитуючи системні ресурси.

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

8.4.3.2. Використання евристичного підходу для визначення цілей

Щоб не витрачати час, намагаючись зараз не UNIX-систему, вірус іноді намагався встановити зв'язок з імовірною мішенню за допомогою telnet або rsh; якщо це не вдавалося, то вірус і не намагався її заразити. Завдяки цьому деякі системи уникнули зараження, т. К., Хоча і підтримували електронну пошту, але відмовляли в доступі telnet або rsh.

8.4.3.3. Невикористані можливості вірусу

Вірус не використав деякі очевидні можливості:

• при пошуку списку мішеней для атаки він міг би використовувати службу DNS для пошуку імен машин, підключених до мережі. Ця інформація зазвичай включає також тип машини і ОС, що обмежує список цілей;
• він не атакував послідовно обидва типи машин. Якщо VAX-атака терпіла невдачу, він міг би зробити Sun-атаку, але не робив цього;
• він не намагався знайти привілейованих користувачів на локальній машині.

8.4.4. Докладний аналіз структури і процедур вірусу

У цьому параграфі вірус описується процедура за процедурою. Взаємозв'язок між процедурами показана на рис. 8.1.

Мал. 8.1. Структура вірусу.

8.4.4.1. імена

Ядро вірусу складається з двох бінарних модулів: один для машин VAX-архітектури, іншої для Sun-архітектури. Це об'єктні файли, що містять списки імен своїх внутрішніх процедур.

Дивно, що ці імена осмислені (наприклад, doit або cracksome), адже такий простий метод, як випадковий вибір імен процедур, міг би сильно ускладнити аналіз вірусу.

8.4.4.1.1. Обробка аргументів командного рядка

Вірус міг запускатися з аргументом "-p NNN", де NNN - десяткове число, яке є ідентифікатором породив процесу. Згодом вірус використовував це число для видалення даного процесу з метою "замітання слідів".

Інші аргументи командного рядка були іменами файлів, які він намагався завантажити. Якщо не вдавалося завантажити хоча б один з них, вірус закінчував роботу. Якщо був заданий аргумент "-p NNN", то він так само стирав файли і потім намагався знищити свій образ на диску.

Потім вірус робив такі дії (причому, якщо якісь з них зазнавали невдачі, він завершувався):

• перевіряв, що був заданий хоча б один файл в командному рядку;
• перевіряв, чи був успішно завантажений файл ll.c.

Якщо була задана опція "-p", програма закривала всі файли, відкриті породив процесом.

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

Вірус сканував всі мережеві інтерфейси, отримував статус і адреси кожного інтерфейсу.

Вірус знищував процес, заданий опцією "-p NNN" і перед цим міняв групу (GID) з поточною діяльністю, щоб не загинути разом з ним.

Якщо всі ці дії закінчувалися вдало, далі він виконував процедуру doit, яка здійснювала іншу роботу.

8.4.4.2. процедура doit

Процедура doit складається з двох частин - ініціалізації і основного циклу.

8.4.4.2.1. Ініціалізація процедури doit

У ній инициализируется генератор випадкових чисел; крім того, вірус зберігає час для подальшого визначення того, як довго він працював в системі.

Потім викликається процедура hg. Якщо вона закінчується невдало, викликається процедура ha.

Після цього з ймовірністю шість сьомих (це було зроблено спеціально) перевіряється, чи існує на даній машині працює копія вірусу (див. 8.4.3.1).

На останньому етапі процедура ініціалізації повинна була за задумом автора посилати байт за адресою 128.32.137.13, відповідному ernie.berke-ley.edu, в порт 11357. Таке ніколи не відбувалося, так як автор неправильно використовував виклик функції.

8.4.4.2.2. Основний цикл процедури doit

Це нескінченний цикл, що містить найбільш активні компоненти вірусу. У ньому викликається процедура cracksome, яка намагається знайти комп'ютери, в які можна проникнути. Потім, після 30-секундного очікування, під час якого відбувається спроба зв'язатися з іншими вірусами, вірус намагається проникнути в інші машини.

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

Потім процедури hd, hl і ha шукають машини для зараження (див. 8.4.4.4), і програма чекає ще 2 хвилини.

Нарешті, перед поверненням на початок циклу, перевіряється значення глобальної змінної pleasequit. Якщо вона встановлена ​​і якщо вірус вже перебрав більше 10 слів з власного словника паролів, вірус завершує роботу. Таким чином, примусова установка pleasequit не дає ефекту моментального завершення всіх вірусів.

8.4.4.3. Процедури підбору пароля

ЦІ процедури є "мозком" вірусу. Cracksome - процедура, яка застосовує Різні стратегії для Проникнення в систему Шляхом підбору паролів Користувачів. Автором допускалося додавання нових стратегій в разі подальшого розвитку вірусу. Вірус послідовно намагається кожну стратегію.

8.4.4.3.1. фаза 0

Це попередній етап, на якому визначається список можливих мішеней для атаки (імена і мережеві адреси комп'ютерів, імена і паролі користувачів).

На цьому етапі читається файл /etc/hosts.equiv в пошуках імен машин, які могли б бути заражені. Цей файл містить інформацію про те, які машини довіряють даної. Логічно припустити, що користувачі цієї машини можуть бути користувачами машин з цього списку.

Після цього читається файл .rhost, що представляє собою список машин, яким дана машина довіряє привілейований доступ. Зауважимо, що це не дає можливості отримання доступу до віддаленої машині і може служити тільки в якості можливого адреси для атаки. Часто системні адміністратори забороняють доступ до цього файлу, через що вірус не міг його прочитати, хоча .rhosts дуже часто є частиною /etс/hosts.equiv.

У висновку фази 0 вірус читає файл паролів / etc / passwd. Інформація з цього файлу використовується для знаходження персональних .forward-файлів, і ті проглядаються з метою пошуку імен машин, які можна атакувати. Крім того, запам'ятовуються імена користувачів, зашифровані паролі та інформаційні рядки GECOS, що зберігаються в файлі / etc / passwd. Після того, як вірус просканував весь файл, він переходить до перебору стратегій.

8.4.4.3.2 .. Стратегія 1

Це найпростіша стратегія, здатна визначити тільки примітивні паролі. В якості пароля пропонуються наступні варіанти (для прикладу візьмемо рядок з файлу etc / passwd

• пароль взагалі відсутня;
• в якості пароля береться вхідний ім'я користувача (user);
• то ж, але прочитане справа наліво (resu);
• пароль є подвійним повтор імені користувача (useruser);
• ім'я або прізвище користувача (Last, First);
• то ж, але в нижньому регістрі (last, first).

Всі ці атаки застосовувалися до 50 паролів, накопиченим під час фази 0. Так як вірус намагався вгадати паролі всіх користувачів, він переходив до стратегії 2.

8.4.4.3.3. стратегія 2

Стратегія 2 використовує внутрішній список з 432 можливих паролів, які є, з точки зору автора вірусу, найбільш підходящими кандидатами на цю роль. У циклі перевірки перевіряється значення змінної pleasequit, щоб перед виходом вірус перевірив не менше 10 варіантів. Список міститься в закодованому вигляді (встановлений старший біт) і перемішується на початку перевірки для того, щоб паролі підбиралися у випадковому порядку.

Коли список слів вичерпаний, вірус переходить до стратегії 3.

8.4.4.3.4. стратегія 3

Ця стратегія використовує для підбору пароля файл / usr / dict / words, що містить близько 24000 слів і використовуваний в системі 4.3BSD (і інших UNIX системах) як словник для перевірки орфографії. Якщо слово починається з великої літери, то також перевіряється і варіант з малої літери.

8.4.4.4. Процедури пошуку віддалених машин

Це набір процедур з починаються на "h" іменами, що виконують завдання пошуку імен і адрес віддалених машин.

Процедура hg викликає процедуру rt_init, яка сканує таблицю маршрутів і записує всі адреси доступних шлюзів (gateways) в спеціальний список. Потім процедура hg намагається застосувати процедури атаки через rsh, finger і sendmail.

Процедура ha зв'язується з кожним шлюзом зі списку, отриманого процедурою hg, через TCP порт номер 23 (telnet), для того, щоб виявити ті машини, які підтримують telnet. Список перемішується випадковим чином, після чого для кожної машини з цього списку викликається процедура hn (т. Е. Вірус намагається заразити все машини в подсетях цього шлюзу).

Процедура hl витягує номер мережі - перший компонент мережевого адреси з усіх адрес поточної машини, і для кожного отриманого адреси викликає процедуру hn до цієї адреси в якості аргументу (інакше кажучи, атакують все локально підключені підмережі).

Процедура hi намагається атакувати кожну машину зі списку, що знаходиться в файлі /etc/hosts.equiv (див. 8.4.4.3), через rsh, finger і sendmail.

Процедура hn отримує номер мережі в якості аргументу. Якщо цей номер збігається з номером мережі однієї з машин, підключених до даної, процедура завершується. Для інших адрес вона намагається вгадати адреси шлюзів шляхом перебору всіх можливих адрес (<номер мережі>. [1-8] .0. [1-255]). Цей список перемішується випадковим чином, після чого процедура намагається атакувати до 12 машин з цього списку, використовуючи rsh, finger і SMTP. Якщо машина не підтримує зв'язок через TCP-порт 514 (rsh), то hn не намагається атакувати її. Після першої успішної атаки процедура завершується.

8.4.4.4.1. Порядок роботи

Всі ці процедури викликаються в головному циклі. Якщо перша процедура завершилася успішно, то інші процедури не викликаються. Кожна процедура повертається після того, як вона зуміла атакувати одну машину. Потім викликається hi, яка намагається заразити віддалені машини, знайдені cracksome. Якщо hi зазнає невдачі, то викликається ha, яка намагається проникнути в найвіддаленіші машину по випадково вгадати адресою зв'язку. Це демонструє, що вірус вважав за краще вражати спочатку шлюзові машини, а потім поширюватися на приєднані до них мережі, замість того щоб заражати машини, минаючи шлюзи. Якщо hg, hi і ha зазнають невдачі, то викликається hl, яка схожа на ha, але підбирає адресу, використовуючи мережеву адресу поточної машини.

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

8.4.4.4.2. Процедура ll.c - "абордажний гак"

Це коротка процедура, яку всі процедури атаки використовували для пересилання основної частини вірусу.

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

Далі процедура (процес-нащадок) створює TCP-зв'язок з заражаємо машиною за адресою, заданому в якості першого аргументу, через порт, заданий другим аргументом. Потім вона пересилає на заражену машину "магічне число", задане третім аргументом. Кожен аргумент стирається відразу ж після його використання. Далі стандартний ввід-висновок перепризначувався на канал зв'язку із зараженою машиною.

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

Після закінчення циклу пересилки файлів запускається Bourne Shell (sh), що заміщає програму ll і отримує команди з зараженої машини.

назад | Зміст | вперед