Несанкціонований доступ до терміналів серверів з операційними системами сімейства UNIX

Міністерство освіти російської федерації

Липецький державний технічний університет

Кафедра АСОІУ

Індивідуальне домашнє завдання з дисципліни «Операційні системи»

«Несанкціонований доступ до терміналів серверів з операційними системами сімейства UNIX. На прикладі octopus. Stu. Lipetsk. Ru »

Виконав: Архипов Н.А.

Група: АС-99-2

Прийняв: Журавльова М.Г.

Липецьк 2001 Передмова

План, що й казати, був чудовий: простий і ясний, краще не придумаєш. Недолік у нього був тільки один: було зовсім невідомо, як привести його у виконання.

Л. Керрол. Аліса в країні чудес

У даному звіті ми спробуємо виявити «дірки» і «вади» локальної комп'ютерної мережі ЛДТУ (LSTU) в цілому і зокрема сервера для вивчення операційних систем UNIX - octopus.lstu. Для цього ми розповімо про можливі спроби отримання доступу до терміналів серверів, у тому числі і з правами root'a, а так само спроба перезавантажити сервер. Тут не розглядається такий вид атаки як «Соціальна інженерія», оскільки наше завдання - вивчення операційних систем, а не психології. Відразу попереджаю, що на практиці не використовувалося ні яких деструктивних дій (у тому числі перевантаження сервера), крім тих дій, які використовувалися тільки для вивчення мережі. Тому, ми ні якої відповідальності за використання цього документа не несемо.

Особливості безпеки комп'ютерних мереж

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

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

віддалені атаки на хост iNterNet

Багато що наша Земля побачила, Але не бачила Такого скандалу!

Б. Заходер. Географія некруто

Аналіз мережевого трафіку Internet

У Internet базовими протоколами віддаленого доступу є TELNET і FTP (File Transfer Protocol). TELNET - це протокол віртуального терміналу (ОТ), що дозволяє з віддалених хостів підключатися до серверів Internet в режимі Вт FTP - протокол, призначений для передачі файлів між віддаленими хостами. Для отримання доступу до сервера за даними протоколів користувачеві необхідно пройти процедури ідентифікації і аутентифікації. У якості інформації, що ідентифікує користувача, виступає його ім'я, а для аутентифікації використовується пароль. Особливістю протоколів FTP і TELNET є те, що паролі і ідентифікатори користувачів передаються по мережі у відкритому, незашифрованому вигляді. Таким чином, необхідною і достатньою умовою для отримання віддаленого доступу до хостів по протоколах FTP і TELNET є ім'я і пароль користувача.

Одним із способів отримання таких паролів і ідентифікаторів в Internet є аналіз мережевого трафіку. Цей аналіз здійснюється за допомогою спеціальної програми-аналізатора пакетів (sniffer), перехоплює всі пакети, передані по сегменту мережі, і виділяє серед них ті, в яких передаються ідентифікатор користувача і його пароль. Мережний аналіз протоколів FTP і TELNET показує, що TELNET розбиває пароль на символи і пересилає їх по одному, поміщаючи кожен символ пароля у відповідний пакет, a FTP, навпаки, пересилає пароль цілком в одному пакеті.

Виникає питання: а чому б не зробити передачу ім'я користувача та пароль у зашифрованому вигляді? Мабуть, проблема в тому, що базові прикладні протоколи сімейства TCP / IP розроблялися дуже давно, в період з кінця 60-х до початку 80-х років, і з тих пір абсолютно не змінилися. При цьому точка зору на побудову глобальних мереж стала іншою. Інфраструктура Мережі та її протоколи розроблялися виходячи, в основному, з міркувань надійності зв'язку, але не з міркувань безпеки.

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

Перебір паролів в файлі / etc / passwd

У ранніх версіях операційних системах сімейства UNIX зашифровані паролі (точніше їх хеш-копії) зберігалися у файлі / etc / passwd. У сучасних UNIX'ах паролі зберігаються в / etc / shadow. Зберігання зашифрованих паролів в / etc / passwd робить систему сервера octopus.lstu вразливою. Тут використовується хеш-функція Data Encryption Standard (DES 48/64 4K). Оскільки дана шифровка працює тільки «в одну сторону», а перевірка автентичності пароля полягає в тому, що при введенні пароля користувача, операційна система шифрує введену послідовність і порівнює її з рядком у файлі / etc / passwd. Ось приклад запису паролів та імен користувачів в / etc / passwd:

root: LyavHDdahFcwU: 0:1: Superuser: /:

...

malysh: 7DnDkTMD9/wG2: 1007:25: Olga A. Bocharnikova, AS-98-1: / user/students/as98/malysh:

Local profile

Повне ім'я

ID і група

Заш. пароль

User name

Для перебору паролів ми використовуємо той же метод, що і операційна система: перебираю всі можливі комбінації літер латинського алфавіту (причому має значення прописна буква або рядкова), цифр і спеціальних знаків. Тут можна використовувати як функції самої операційної системи, так і написати свою функцію шифрування. Але треба бути точно впевненим що за алгоритм використовується в даному випадку, інакше перебір не призведе ні до яких результатів. На комп'ютері octopus використовується алгоритм шифрування DES [48/64 4K]. Так як на octopus'e настільки кепські, за сьогоднішніми мірками, апаратні засоби (див. наступний пункт), то ні про яке переборі пароля не може йти й мови. Тим більше, навіть на більш швидких машинах (Pentium III - 650MHz) розшифровка зайняла приблизно 30 діб (!!!). Та і сервер не весь час знаходиться в робочому стані, як вже було відмічено вище. У звіті додається частина програми, для розшифровки паролів файлу / etc / passwd.

Deny of Service (DoS) атака.

Дослівно Deny of Service перекладається як «відмова в обслуговуванні». Це означає наприклад, що операційна система не може обслужити запит користувача або іншої системи.

Розглянемо порушення працездатності хосту в мережі при використанні направленого шторму хибних TCP-запитів на створення з'єднання або при переповненні черги запитів. З розглянутої в попередньому пункті схеми створення TCP-з'єднання слід, що на кожний отриманий TCP-запит (TCP SYN) операційна система повинна згенерувати початкове значення ідентифікатора ISN і відіслати його на запитав хост. Але так як в Internet (стандарту IPv4) не передбачений контроль за IP-адресою відправника повідомлення, то простежити справжній маршрут, пройдений IP-пакетом, неможливо і, отже, у кінцевих абонентів мережі немає способу обмежити число запитів, що приймаються в одиницю часу від одного хоста. Тому можливе здійснення типової віддаленої атаки «відмова в обслуговуванні», яка полягатиме в передачі на об'єкт атаки як можна більшого числа помилкових TCP-запитів на створення з'єднання від імені будь-якого хоста в мережі (спрямований шторм запитів TCP SYN, схема якого наведена на малюнку) .

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

Таку атаку можна було передбачити ще років двадцять тому, коли з'явилося сімейство протоколів TCP / IP: її коріння знаходиться в самій інфраструктурі мережі Internet, в її базових протоколах - IP і TCP. Але яке ж було наше здивування, коли з'ясувалося, що на інформаційному. WWW-сервері CERT (Computer Emergency Respone Team) перша згадка про віддалений вплив такого роду датована тільки 19 вересня 1996 року! Там ця атака мала назву «TCP SYN Flooding and IP Spoofing Attacks» («повінь» TCP-запитами з помилкових IP-адрес). Інший різновид атаки «відмова в обслуговуванні» полягає в передачі на атакується хост кількох десятків (сотень) запитів TCP SYN в секунду (спрямований міні-шторм TCP-запитів) на підключення до сервера, що може призвести до тимчасового (до 10 хвилин) переповнення черги запитів на сервері (див. атаку К. Митника). Це відбувається через те, що деякі мережеві ОС обробляють тільки перші декілька запитів на підключення, а інші ігнорують, Таким чином, отримавши N запитів на підключення, ОС сервера ставить їх у чергу і генерує відповідно N відповідей. Потім протягом певного проміжку часу (тайм-аут <10 хвилин) сервер буде чекати повідомлення від передбачуваного клієнта, щоб завершити handshake і підтвердити створення віртуального каналу із сервером. Якщо атакуючий надішле таку кількість запитів на підключення, яке дорівнює максимальному числу одночасно оброблюваних сервером повідомлень, то протягом тайм-ауту інші запити будуть ігноруватися і встановити зв'язок з сервером не вдасться.

Ми провели ряд експериментів з направленим штормом і спрямованим мініштормом запитів на різних за обчислювальних потужностей комп'ютерах з різними операційними системами.

Тестування спрямованим штормом запитів TCP SYN, що проводиться на різних мережевих ОС в експериментальних 10-мегабітних сегментах мережі, дало наступні результати: всі описані далі атаки здійснювалися за певною методикою. Підготовлявся TCP-запит, який за допомогою спеціально розробленої власної програми в циклі передавався в мережу з відповідними затримками (аж до нульової) між запитами. При цьому циклічно змінювалися такі параметри запиту, як порт відправника і значення 32-бітного ідентифікатора SYN. IP-адреса відправника запиту був вибраний так, щоб, по-перше, цей хост зараз не був активний в мережі і, по-друге, щоб відповідний маршрутизатор, в чиїй зоні відповідальності знаходиться даний хост, не надсилав повідомлення Host Unreachable (Хост недоступний). В іншому випадку хост, від імені (з IP-адреси) якого посилався запит TCP SYN, отримавши «несподіваний» відповідь TCP АСК від атакується сервера, перешле на нього пакет TCP RST, закриваючи в такий спосіб з'єднання.

При передачі по каналу зв'язку максимально можливого числа TCP-запитів і при знаходженні кракерами в одному сегменті з об'єктом атаки атакуються системи вели себе таким чином: ОС Windows 95, встановлена на 486DX2-66 з 8 Мб ОЗУ, «завмирала» і переставала реагувати на будь-які зовнішні впливи (зокрема, натискання на клавіатуру); ОС Linux 2.0.0 на 486DX4-133 з 8 Мб ОЗУ також практично не функціонувала, обробляючи одне натискання на клавіатурі приблизно 30 секунд. У результаті до цих хостам неможливо було отримати не тільки віддалений, але і локальний доступ.

Не менш цікавим було поведінку атакованих систем після зняття впливу: ОС Windows 95 практично відразу ж після припинення атаки почала нормально функціонувати; в ОС Linux 2.0.0 з 8 Мб ОЗУ, мабуть, переповнився буфер, і більше півгодини система не функціонувала ні для віддалених, ні для локальних користувачів, а займалася лише передачею відповідей на отримані раніше запити. CyberGuard відразу ж після зняття впливу став доступним для віддаленого доступу.

Якщо кракер знаходився в суміжних сегментах з об'єктом, то під час атаки ОС Windows 95 на Pentium 100 з 16 Мб ОЗУ обробляла кожне натискання з клавіатури приблизно секунду, ОС Linux 2.0.0 на Pentium 100 з 16 Мб ОЗУ практично «повисала» - одне натискання за 30 секунд, зате після зняття впливу нормальна робота поновлювалася.

Не потрібно обманюватися, вважаючи, що ОС Windows 95 показала себе з кращого боку. Такий результат пояснюється наступним: Windows 95 - операційна система, яка не має FTP-сервера, а отже, їй не потрібно було зберігати в пам'яті параметри переданого TCP-запиту на підключення до цього сервера і чекати закінчення handshake.

Таким чином, враховуючи апаратні засоби сервера octopus.lstu (Olivetti 80286) можна без зусиль здійснити на нього DoS атаку. Навіть якщо локальна мережа буде завантажена. Можна припустити, що й інші сервера університету можуть бути «знерухомлені» таким способом. Наприклад сервер кафедри прикладної математики: IBM 486DX66 16RAM. За апаратної частини сервери кафедри АСУ (тут не мається на увазі octopus.lstu) більш стійкі до DoS атаки.

Перевищення максимально можливого розміру IP-пакета, або Ping Death

У максимальний розмір IP-пакета (65 535 байт) включаються довжина IP-заголовка і довжина нуля даних в IP-пакеті. Так як мінімальний розмір IP-заголовка - 20 байт (максимальний - 60), то відповідно розмір даних, переданих в одному IP-пакеті, не може перевищувати 65 535 - 20 = 65 515 байт. А що буде, якщо перевищити це число? Тестувати свої програми на граничних критичних значеннях-стандартний для будь-якого програміста хід. Подібні тести дозволяють виявити такі неприємні помилки, як всілякі переповнення (буфера, стека, змінної і т. д.). Але повернемося до IP. В принципі ніщо не заважає атакуючому сформувати набір фрагментів, які після складання перевищать максимально можливий розмір IP-пакета. Власне в цій фразі і сформульована основна ідея цієї атаки.

Отже, 18 грудня 2000 року на інформаційному сервері СЕКТ з'явилися повідомлення про те, що більшість мережевих операційних систем, що підтримують протоколи TCP / IP, володіють наступною уразливістю: при передачі на них IP-пакета довжиною, що перевищує максимально допустиме значення, в цих ОС переповнюється буфер або змінна, в результаті система «зависає» або перезавантажувати, тобто в наявності відмова в обслуговуванні. Був наведений і список потенційно небезпечних платформ:

• Berkeley Software Design, Inc. (BSD);

• Computer Associates, Intl. (Products for NCR);

• Cray Research;

• Digital Equipment Corporation;

• FreeBSD, Inc.; 'Hewlett-Packard Company;

• IBM Corporation;

• Linux Systems;

• NEC Corporation;

• Open Software Foundation (OSF);

• The Santa Cruz Operation, Inc. (SCO);

• Sun Microsystems, Inc.

Ми з подивом прочитали цей перелік операційних систем на різних платформах, а потім взялися за експерименти. Наше глибоке здивування викликав той факт, що елементарну помилку переповнювання буфера в модулі IP ядра ОС за майже 20 років активного функціонування протоколу IP розробники сьогоднішніх систем до сих пір не помічали. Тому ми дозволили собі не повірити такої поважаної організації, як CERT. Але перш ніж почати експерименти, було вирішено подивитися за вказаною в CERT посиланням (http://www.sophist.demon.co.uk/ping) на WWW-сервер, де експертами проводилися подібні дослідження на різних ОС. На WWW-сервері пропонувалося реалізувати такий вплив наступним чином: необхідно виконати на робочій станції з ОС Windows 95 або Windows NT наступну команду: ping-l 65527 victim.destination.IP.address (по цій команді атака і отримала свою назву - Ping Death) .

Так як звичайний розмір IP-заголовка складає 20 байт, а розмір 1СМР-заголовка - 8 байт, то подібний ICMP-пакет буде перевищувати максимально можливий розмір IP-пакета на 20 байт: 65 527 +20 +8-65 535 = 20.

Грунтуючись на наведеному розрахунку, ці «експерти» декларували, що звичайною командою ping можна порушити працездатність практично будь-який мережевий ОС. На завершення пропонувалася така таблиця тестування різних операційних систем

Операційна система	Версія ПЗ	Симптоми
Solaris (x86)	2.4, 2.5, 2.5.1	Перезавантаження
Minix	1.7.4, v2.0 і інші	Збій
HP3000 MPE / iX	4.0, 5.0, 5.5	Скидання системи
Convex SPP-UX	Всі версії	Збій
Apple Mac	MacOs 7.xx	Збій
Windows 3.11 with Trumpet winsock	?	Змішані звіти
Novell Netware	3.x	Змішані звіти
Windows 95	Всі версії	Збій
AIX	3 і 4	Скидання системи
Linux	2.0.23	Спонтанна перезавантаження або зависання (kernel panic)
DEC UNIX / OSF1	2.0 і вище	зависання (kernel panic)
Open VMS for AXP	Різні	Змішані звіти
HP-UX	9.0 по 10.20	Збій, перезавантаження, зависання.
Windows NT	3.5.1	Змішані результати
Irix	5.3	зависання (kernel panic)
Windows NT	4	Збій
SCO Openserver	4.2, 5.0.x	Вразлива
DEC TOPS-20, TOPS-10	Всі	Помилки
Digital Firewall	?	Вразлива
AltaVista Firewall for UNIX	?	Вразлива

(Тут вона приводиться в скороченні), на які дана віддалена атака нібито справила необхідний ефект. Отже, ми почали тестування і, чесно кажучи, абсолютно не здивувалися, коли досліджувані ОС - IRIX, AIX, VMS, SunOs, FreeBSD, Linux, Windows NT 4.0, навіть Windows 95 і Windows for WorkGroups 3.11-абсолютно не реагували на подібний некоректний запит , продовжуючи нормально функціонувати. Тоді були зроблені спеціальні пошуки операційної системи, яку б дійсно вивела з ладу дана атака. Нею виявилася Windows 3.11 з WinQVT - ця ОС справді «зависла».

Цим «експертам», яким настільки довіряють CERT і С1АС, ми надіслали запит, де попросили прояснити ситуацію, що виникла, а також уточнити відомості з вищенаведеної таблиці. В отриманому нами відповіді говорилося, що успіх даної атаки залежить від багатьох факторів, а саме: програмного і апаратного забезпечення, встановленого на комп'ютері, і, найголовніше, від фази Місяця. Як кажуть, без коментарів. Для повноти картини ми хотіли б привести опис exploit, створеного для Windows NT 4.0, завдання якого, використовуючи ping, «завісити» власний комп'ютер (!). Спочатку пропонувалося запустити Web Browser, потім-taskmgr (Task Manager): так Ping Death нібито краще працює (ще не вистачає шаманського бубна!). І нарешті, потрібно запустити 18 ping-процесів (чому не 100?). Якщо ви думаєте, що після всього цього ваша ОС негайно «повисне», то помиляєтеся! У коментарях до exploit до одержання ефекту пропонувалося чекати приблизно 10 хвилин, а може бути, трохи більше або трохи менше.

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

причини успіху віддалених атак

«Те, що винайдено однією людиною,

може бути зрозуміле іншим », - сказав Холмі.

А. Конан Доїв. Танцюючі чоловічки

· Використання нестійких алгоритмів ідентифікації

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

· Відсутність контролю за віртуальними каналами зв'язку

Об'єкти розподіленої ЗС, взаємодіючі по віртуальних каналах, можуть піддаватися типової атаці «відмова в обслуговуванні». Особливість цього впливу полягає в тому, що, діючи абсолютно легальними засобами системи, можна віддалено домогтися порушення її працездатності. У чому причина успіху даної атаки? У відсутності необхідного контролю над з'єднанням. При цьому завдання контролю розпадається на дві підзадачі:

• контроль за створенням з'єднання;

• контроль за використанням з'єднання.

Якщо шляхи вирішення другого завдання зрозумілі - зазвичай з'єднання розривається з тайм-ауту, визначеному системою, - так зроблено в усіх відомих мережевих ОС (проте тут виникає серйозна проблема вибору конкретного значення тайм-ауту), то контроль за створенням ВК досить складний: в системі , де відсутня статична ключова інформація про всі її об'єктах, неможливо відокремити помилкові запити на створення з'єднання від справжніх. Очевидно також, що якщо один суб'єкт мережевої взаємодії буде мати можливість анонімно займати необмежене число каналів зв'язку з віддаленим об'єктом, то подібна система може бути повністю паралізована даним суб'єктом. Таким чином, якщо будь-який об'єкт у розподіленій системі здатний анонімно надіслати повідомлення від імені іншого об'єкта (наприклад, в Internet маршрутизатори не перевіряють IP-адреса відправника), то в подібній розподіленої ВС практично неможливий контроль за створенням віртуальних з'єднань. Тому основна причина типової загрози «відмова в обслуговуванні» - це відсутність прийнятного рішення задачі контролю за маршрутом повідомлень.

· Відсутність можливості контролювати маршрут повідомлень

Якщо у РВС не передбачити контролю за маршрутом повідомлення, то адреса відправника повідомлення виявляється нічим не підтвердженими. Таким чином, в системі буде існувати можливість роботи від імені будь-якого об'єкта шляхом зазначення в заголовку повідомлення чужого адреси відправника (IP Spoofing). У подібній РВС важко визначити, звідки насправді прийшло повідомлення, а отже - обчислити координати атакуючого (в Internet неможливо знайти ініціатора односпрямованої віддаленої атаки).

· Відсутність повної інформації про об'єкти РВС

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

· Відсутність криптозахисту повідомлень

У розподілених ОС зв'язок між об'єктами системи здійснюється по віртуальних каналах зв'язку, а отже, хакер має принципову можливість прослухати канал, одержавши несанкціонований доступ до інформації, якою обмінюються по мережі се абоненти. Якщо ця інформація не зашифрована, то виникає загроза атаки типу «аналіз мережевого трафіку».

· Відсутність виділеного каналу зв'язку між об'єктами мережі Internet

Глобальна мережа не може бути побудована за принципом прямого зв'язку між об'єктами, оскільки для кожного об'єкта неможливо забезпечити ви ділений канал зв'язку з будь-яким іншим об'єктом. Тому в Internet зв'язок здійснюється через ланцюжок маршрутизаторів, а отже, повідомлення, проходячи через велику кількість проміжних підмереж, може бути перехоплено. Також до Internet підключено велику кількість локальних Ethernet-мереж, що використовують топологію «загальна шина»; в мережах з такою

топологією нескладно програмно здійснювати перехоплення повідомлень.

· Недостатні ідентифікація та аутентифікація

У базових протоколах обміну ідентифікація та аутентифікація об'єктів практично відсутні. Так, наприклад, у прикладних протоколах. FTP, TELNET, РОРЗ імена і паролі користувачів передаються по мережі у вигляді відкритих незашифрованих повідомлень.

· Використання нестійких алгоритмів ідентифікації об'єктів при створенні віртуального TCP-з'єднання

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

· Відсутність криптозахисту повідомлень

В існуючих базових протоколах сімейства TCP / IP, забезпечують взаємодію на мережному і транспортному рівнях, не передбачена можливість шифрування повідомлень, хоча очевидно, що додати її до протоколу TCP не становило жодних проблем. Розробники вирішили перекласти завдання криптозахисту на протоколи більш високих рівнів, наприклад прикладного рівня. При цьому базові протоколи прикладного рівня (FTP, TELNET, HTTP та ін) також не передбачали ніякого шифрування повідомлень. Тільки не так давно з'явився загальнодоступний прикладної протокол SSL, вбудований в Netscape Navigator, що дозволяє як надійно зашифрувати повідомлення, так і підтвердити його справжність. На закінчення хотілося б зауважити, що всі описані вище причини, по яких можлива успішна реалізація загроз безпеки РВС, роблять мережу Internet небезпечною. А отже, всі користувачі мережі можуть бути атаковані в будь-який момент.

Підіб'ємо підсумки.

Враховуючи все вищесказане, я думаю, що студентам кафедри АСОІУ вже зараз не представляється ніякої складності для несанкціонованого доступу до терміналів серверів з правами адміністраторів (причому це не необгрунтоване висловлювання). Інше питання - доцільності всього цього. Я думаю що не варто перевіряти все вищесказане на практиці в цілях своєї ж безпеки.

У цілому, обчислювальна мережа університету адмініструється вельми непогано, потрібно віддати належне системним адміністраторам. На серверах стоять останні версії операційних систем. Однак на chuck.stu.lipetsk.ru чомусь у звичайних користувачів немає прав на компілювання Сі програм. Чому? Може це і є слабка ланка в адмініструванні, чи це ще одна пересторога адміністратора? Хоча на tomcat.am.lstu звичайним смертним дозволено ...

Взагалі-то злом octopus.stu.lipetsk.ru був би неповагою своєї ж кафедри. Адже та захист яка там присутня спрямована не для того, щоб запобігти проникненню зловмисника, а для елементарного захисту від недосвідчених користувачів.

ДОДАТОК.

В цілях безпеки, наводимо тільки фрагменти програми. Файл john.c

# Include <stdio.h>

# Include <string.h>

# Include <stdlib.h>

# Include <sys/stat.h>

# Include "arch.h"

# Include "misc.h"

# Include "params.h"

# Include "path.h"

# Include "memory.h"

# Include "list.h"

# Include "tty.h"

# Include "signals.h"

# Include "idle.h"

# Include "common.h"

# Include "formats.h"

# Include "loader.h"

# Include "logger.h"

# Include "status.h"

# Include "options.h"

# Include "config.h"

# Include "bench.h"

# Include "charset.h"

# Include "single.h"

# Include "wordlist.h"

# Include "inc.h"

# Include "external.h"

# Include "batch.h"

# If CPU_DETECT

extern int CPU_detect ();

# Endif

extern struct fmt_main fmt_DES, fmt_BSDI, fmt_MD5, fmt_BF;

extern struct fmt_main fmt_AFS, fmt_LM;

extern int unshadow (int argc, char ** argv);

extern int unafs (int argc, char ** argv);

extern int unique (int argc, char ** argv);

static struct db_main database;

static struct fmt_main dummy_format;

static void john_register_one (struct fmt_main * format)

{

if (options.format)

if (strcmp (options.format, format-> params.label)) return;

fmt_register (format);

}

static void john_register_all ()

{

if (options.format) strlwr (options.format);

john_register_one (& fmt_DES);

john_register_one (& fmt_BSDI);

john_register_one (& fmt_MD5);

john_register_one (& fmt_BF);

john_register_one (& fmt_AFS);

john_register_one (& fmt_LM);

if (! fmt_list) {

fprintf (stderr, "Unknown ciphertext format name requestedn");

error ();

}

static void john_load ()

{

struct list_entry * current;

umask (077);

if (options.flags & FLG_EXTERNAL_CHK)

ext_init (options.external);

if (options.flags & FLG_MAKECHARS_CHK) {

options.loader.flags | = DB_CRACKED;

ldr_init_database (& database, & options.loader);

if (options.flags & FLG_PASSWD) {

ldr_show_pot_file (& database, LOG_NAME);

database.options-> flags | = DB_PLAINTEXTS;

if ((current = options.passwd-> head))

do {

ldr_show_pw_file (& database, current-> data);

} While ((current = current-> next));

} Else {

database.options-> flags | = DB_PLAINTEXTS;

ldr_show_pot_file (& database, LOG_NAME);

}

return;

}

if (options.flags & FLG_STDOUT) {

ldr_init_database (& database, & options.loader);

database.format = & dummy_format;

memset (& dummy_format, 0, sizeof (dummy_format));

dummy_format.params.plaintext_length = options.length;

dummy_format.params.flags = FMT_CASE | FMT_8_BIT;

}

if (options.flags & FLG_PASSWD) {

if (options.flags & FLG_SHOW_CHK) {

options.loader.flags | = DB_CRACKED;

ldr_init_database (& database, & options.loader);

ldr_show_pot_file (& database, LOG_NAME);

if ((current = options.passwd-> head))

do {

ldr_show_pw_file (& database, current-> data);

} While ((current = current-> next));

printf ("% s% d password% s cracked,% d leftn",

database.guess_count? "N": "",

database.guess_count,

database.guess_count! = 1? "S": "",

database.password_count -

database.guess_count);

return;

}

if (options.flags & (FLG_SINGLE_CHK | FLG_BATCH_CHK))

options.loader.flags | = DB_WORDS;

else

if (mem_saving_level)

options.loader.flags & = ~ DB_LOGIN;

ldr_init_database (& database, & options.loader);

if ((current = options.passwd-> head))

do {

ldr_load_pw_file (& database, current-> data);

} While ((current = current-> next));

ldr_load_pot_file (& database, LOG_NAME);

ldr_fix_database (& database);

printf ("Loaded% d password% s% s",

database.password_count,

database.password_count! = 1? "S": "",

database.password_count? "": ", Exiting ...");

if (database.password_count> 1) {

printf ("with");

printf (database.salt_count! = 1? "% d": "no",

database.salt_count);

printf ("different salts");

}

if (database.password_count)

printf ("(% s [% s]) n",

database.format-> params.format_name,

database.format-> params.algorithm_name);

else

putchar ('n');

if ((options.flags & FLG_PWD_REQ) & &! database.salts) exit (0);

}

static void john_init (int argc, char ** argv)

{

# If CPU_DETECT

if (! CPU_detect ()) {

# If CPU_REQ

fprintf (stderr, "Sorry,% s is requiredn", CPU_NAME);

error ();

# Endif

}

# Endif

path_init (argv);

cfg_init (CFG_NAME);

status_init (NULL, 1);

opt_init (argc, argv);

john_register_all ();

common_init ();

sig_init (idle_yield);

john_load ();

}

static void john_run ()

{

if (options.flags & FLG_TEST_CHK)

benchmark_all ();

else

if (options.flags & FLG_MAKECHARS_CHK)

do_makechars (& database, options.charset);

else

if (options.flags & FLG_CRACKING_CHK) {

if (! (options.flags & FLG_STDOUT)) log_init (LOG_NAME);

tty_init ();

if (options.flags & FLG_SINGLE_CHK)

do_single_crack (& database);

else

if (options.flags & FLG_WORDLIST_CHK)

do_wordlist_crack (& database, options.wordlist,

(Options.flags & FLG_RULES)! = 0);

else

if (options.flags & FLG_INC_CHK)

do_incremental_crack (& database, options.charset);

else

if (options.flags & FLG_EXTERNAL_CHK)

do_external_crack (& database);

else

if (options.flags & FLG_BATCH_CHK)

do_batch_crack (& database);

status_print ();

tty_done ();

if (! (options.flags & FLG_STDOUT)) log_done ();

}

static void john_done ()

{

path_done ();

check_abort ();

}

int main (int argc, char ** argv)

{

char * name;

# Ifdef __DJGPP__

if (- argc <= 0) return 1;

if ((name = strrchr (argv [0],'/')))

strcpy (name + 1, argv [1]);

name = argv [1];

argv [1] = argv [0];

argv + +;

# Else

if (! argv [0])

name = "";

else

if ((name = strrchr (argv [0],'/')))

name + +;

else

name = argv [0];

# Endif

# Ifdef __CYGWIN32__

if (strlen (name)> 4)

if (! strcmp (strlwr (name) + strlen (name) - 4, ". exe"))

name [strlen (name) - 4] = 0;

# Endif

if (! strcmp (name, "john")) {

john_init (argc, argv);

john_run ();

john_done ();

return 0;

}

if (! strcmp (name, "unshadow"))

return unshadow (argc, argv);

if (! strcmp (name, "unafs"))

return unafs (argc, argv);

if (! strcmp (name, "unique"))

return unique (argc, argv);

fprintf (stderr, "Sorry, I can't find myselfn");

return 1;

}

Файл des_bs.c

# Include <string.h>

# Include "arch.h"

# Include "DES_std.h"

# Include "DES_bs.h"

DES_bs_combined DES_bs_all;

int DES_bs_mem_saving = 0;

extern void DES_bs_body ();

void DES_bs_init ()

{

int index, bit;

for (index = 0; index <0x300; index + +) {

bit = DES_K_bits [index];

bit -= bit>> 3;

DES_bs_all.Kp [index] = & DES_bs_all.K [55 - bit];

}

void DES_bs_set_salt (ARCH_WORD salt)

{

mask = 1;

for (dst = 0; dst <48; dst + +) {

if (dst == 24) mask = 1;

if (salt & mask) {

if (dst <24) src = dst + 24; else src = dst - 24;

} Else src = dst;

DES_bs_all.E [dst] = & DES_bs_all.B [DES_E [src]];

DES_bs_all.E [dst + 48] = & DES_bs_all.B [DES_E [src] + 32];

mask <<= 1;

}

void DES_bs_clear_keys ()

{

memset (DES_bs_all.K, 0, sizeof (DES_bs_all.K));

}

void DES_bs_set_key (char * key, int index)

{

ofs = 56;

for (ptr = key; * ptr & & ofs; ptr + +) {

bit = (ofs -= 7);

value = * ptr & 0x7F;

do {

DES_bs_all.K [bit + +] | = (value & 1) <<index;

} While (value>> = 1);

}

void DES_bs_crypt (int count)

{

memset (DES_bs_all.B, 0, sizeof (DES_bs_all.B));

do {

DES_bs_body ();

if (! - count) break;

for (bit = 0; bit <32; bit + +) {

R = DES_bs_all.B [bit];

L = DES_bs_all.B [bit + 32];

DES_bs_all.B [bit + 32] = R;

DES_bs_all.B [bit] = L;

}

} While (1);

}

ARCH_WORD * DES_bs_get_binary (char * ciphertext)

{

static ARCH_WORD out [64];

ARCH_WORD * raw;

int bit;

int index, shift;

int value;

raw = DES_raw_get_binary (ciphertext);

out [1] = out [0] = 0;

for (bit = 0; bit <64; bit + +) {

index = bit>> 4;

/ * Swap L and R here instead of doing it one more time in DES_bs_crypt () * /

index ^ = 2;

/ * Calculate the number of one of the 16 data bits in raw [index] * /

shift = ((bit & 0xC) <<1) + (bit & 3) + 1;

/ * Get the bit * /

value = (raw [index]>> shift) & 1;

if (DES_bs_mem_saving)

/ * Memory saving: pack the bits into two words * /

out [bit>> 5] | = value <<(bit & 0x1F);

else

/ * We either set or clear all the bits in every word * /

out [bit] = value? ~ (ARCH_WORD) 0: 0;

}

return out;

}

int DES_bs_binary_hash (ARCH_WORD * binary, int count)

{

int bit, result;

if (DES_bs_mem_saving)

return (int) * binary & ((1 <<count) - 1);

result = 0;

for (bit = 0; bit <count; bit + +)

if (binary [bit]) result | = 1 <<bit;

return result;

}

int DES_bs_get_hash (int index, int count)

{

mask = (ARCH_WORD) 1 <<index;

result = 0;

for (bit = 0; bit <count; bit + +)

if (DES_bs_all.B [bit] & mask) result | = 1 <<bit;

return result;

}

/ *

* The trick I used here allows to compare one ciphertext against all the

* DES_bs_crypt () outputs in just O (log2 (ARCH_BITS)) operations.

* /

int DES_bs_cmp_all (ARCH_WORD * binary, int count)

{

mask = 0;

if (DES_bs_mem_saving)

for (bit = 0; bit <((count <32)? count: 32); bit + +) {

mask | = DES_bs_all.B [bit] ^

((Binary [0] & (1 <<bit))? ~ (ARCH_WORD) 0: 0);

if (mask == ~ (ARCH_WORD) 0) return 0;

}

else

for (bit = 0; bit <count; bit + +) {

mask | = DES_bs_all.B [bit] ^ binary [bit];

if (mask == ~ (ARCH_WORD) 0) return 0;

}

return 1;

}

int DES_bs_cmp_one (ARCH_WORD * binary, int count, int index)

{

if (DES_bs_mem_saving) {

for (bit = 0; bit <count; bit + +)

if (((DES_bs_all.B [bit]>> index) ^

(Binary [bit>> 5]>> (bit & 0x1F))) & 1) return 0;

return 1;

}

mask = (ARCH_WORD) 1 <<index;

for (bit = 0; bit <count; bit + +)

if ((DES_bs_all.B [bit] ^ binary [bit]) & mask) return 0;

return 1;

}