Nпорушник шляхом прослуховування telnet-сеансів може отримати ім’я користувача і його пароль, і в подальшому скористатись ними

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

NРяд сучасних RFC, що мають статус пропозицій стандартів, специфікують різні опції автентифікації і шифрування в Telnet

NІншим рішенням є використання протоколу SSH замість Telnet

¨Так поступають для задач адміністрування UNIX-серверів і мережного обладнання деяких виробників

Атаки на сервер Telnet

NПротокол Telnet має не дуже широко відому можливість, яка суттєво впливає на безпеку сервера

NКлієнт має можливість впливати на змінні оточення сервера ще до автентифікації

¨Ця можливість підтримується багатьма сучасними серверами Telnet

¨Вона може бути використана, наприклад, для атаки на FTP-сервер, який дозволяє анонімне завантаження файлів

¨Порушник може, користуючись протоколом FTP, спочатку завантажити модифіковану бібліотеку (наприклад, libc), яка містить бажані для нього функції, або взагалі “троянського коня” під добре відомим ім’ям (наприклад, ls), а потім відкрити Telnet-сесію, і змінити змінну оточення, що вказує на бібліотеку, або змінну PATH

¨Такі атаки нелегко виявити, тому що і змінні оточення, і каталоги, в які є доступ для анонімного завантаження файлів за протоколом FTP, ретельно перевіряють далеко не всі адміністратори

¨Оскільки в наш час описана вразливість добре відома, її наявність в системі (тобто, дозвіл на віддалену модифікацію змінних оточення) слід вважати помилкою адміністрування.

NДеякі сервери Telnet мали класичні помилки переповнення буфера

¨У наш час зловмисникам сподіватись на це не варто, але все ж різні нестандартні сервери Telnet (наприклад, вбудовані в мережне обладнання) повинні ретельно перевірятись на наявність таких помилок

Атаки на клієнта Telnet

NТрадиційно – помилки переповнення буфера

¨Якщо клієнт має таку помилку, то використати її зловмисник може, наприклад, розмістивши на Web-сервері посилання вигляду telnet://server.edu/xxxxxxxx (вважаємо, що за xxxxxxxx якраз і схований спеціально підібраний рядок, що дозволяє виконати на комп’ютері клієнта певну команду)

¨Як тільки недбалий користувач активує таке посилання, його браузер запустить Telnet-клієнта і передасть останньому параметри

¨Такі помилки протягом довгих років були актуальними для Telnet-клієнтів ОС Windows 9x

NЩе одна можливість атаки на клієнта була прихована у драйвері ANSI

¨Основні можливості терміналів обмежувались зміною кольорів і шрифтів

NВикористання таких можливостей не несло небезпеки комп’ютерам клієнтів

¨Але існували такі драйвери ANSI, які підтримували макрокоманди

NПри взаємодії Telnet-клієнта з таким драйвером існувала можливість виконання на комп’ютері клієнта макрокоманд, що були передані з сервера. А це вже є потенціальною вразливістю.

Проблеми з безпекою протоколу FTP

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

¨Пересилання даних також не передбачає додаткового захисту, але це не є великою проблемою:

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

Nякщо потребують захисту цілісності, то вони повинні супроводжуватись електронним підписом

¨Відкритість каналу керування, натомість, відкриває для порушників можливості перехоплення ідентифікаторів і паролів користувачів FTP-сервера

nу FTP атрибути передаються відповідними командами протоколу, кожна з яких передається окремим пакетом. Тому в одному з пакетів є послідовність символів USER: <login_name>, а в наступному PASS: <password>, де login_name і password — ідентифікатор і пароль, що введені користувачем

nДля боротьби з цією вадою в межах протоколів прикладного рівня існують лише два шляхи:

¨відмовитись від протоколу FTP на користь захищених протоколів (які, на жаль, не набули достатнього поширення),

¨або взагалі відмовитись від автентифікації користувачів, зробивши FTP–сервер повністю відкритим та доступним

NІнша проблема FTP — відсутність контролю за походженням пакетів: ці завдання покладаються на засоби транспортного і мережного рівнів

Протокол FTP і брандмауери

NТиповою вимогою політики безпеки, яку виконують міжмережні екрани, є заборона ініціювання з зовнішньої мережі з’єднань з комп’ютерами захищеної мережі

¨Тобто ініціаторами з’єднань можуть виступати лише “свої” комп’ютери

¨Це нормально працює для більшості протоколів, заснованих на технології “клієнт-сервер”: клієнт з захищеної мережі робить запит до сервера, що знаходиться у зовнішній мережі, сервер йому відповідає

¨У протоколі FTP таким чином встановлюється з’єднання лише для каналу керування

¨Як тільки сервер отримує команду, що вимагає пересилання файлів, він зі своєї ініціативи намагається встановити з’єднання з комп’ютером-клієнтом

¨Крім пересилання файлів, так само окремим з’єднанням передається, наприклад, список файлів у поточному каталозі

NБільшість клієнтів, що мають розвинутий інтерфейс користувача, передають запит списку файлів невідкладно після встановлення з’єднання. Все, що побачить користувач, який знаходиться за міжмережним екраном, — це вікно, яке інформує про підключення до сервера і про очікування з’єднання. Список файлів ніколи не буде отриманим, також неможлива буде будь-яка передача файлів.

nВихід з проблеми передбачено у самому протоколі FTP — це так званий пасивний режим

¨У пасивному режимі сервер через канал керування передає клієнту параметри каналу передачі даних (зокрема, номер порту), який він дозволяє створити

¨Ініціатором з’єднання виступає клієнт

¨Це дозволяє нормально працювати з FTP-серверами, навіть знаходячись за брандмауером

NПроблеми взаємодії FTP з міжмережними екранами описані у RFC 1579

NУдосконалення і додаткові можливості протоколу FTP, значна частина яких безпосередньо впливає на безпеку, описані також у RFC 2228, 2428, 2773 та інших

Проксі-режим у протоколі FTP

NОбмеження проксі-режиму практично не описані в документації, але його можливість визначена дуже чітко

¨Суть проксі-режиму полягає в тому, що користувач, зв’язавшись із сервером, може запросити пересилання файлів не лише собі, а й на інший сервер

¨Користувач повинен встановити з’єднання з обома серверами

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

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

NРозробники RFC не дуже детально описали такий режим, можливо, маючи на увазі його подальше детальне опрацювання

¨Очевидно, що сервер може легко розпізнати, що канал передачі даних встановлюється не з тим хостом, з яким встановлено сесію керування

¨Сервери поділяються на ті, що підтримують проксі-режим, і ті, що його не підтримують

NМожна було б вважати, що великої шкоди у проксі-режимі бути не повинно, оскільки користувач все одно повинен мати права встановлювати з’єднання з кожним із серверів — учасників обміну

NІснує одна унікальна можливість, яку надає проксі-режим. Мова йде про техніку прихованого сканування портів — FTP Bounce Attack (прихована атака по FTP)

FTP Bounce Attack

NЯкщо FTP-сервер проінструктований встановити з’єднання з деяким хостом Інтернету, відмінним від хосту клієнта, що підтримує в цей момент із сервером FTP-сесію, то сервер не може знати, чи має насправді клієнт з тим іншим хостом у цей момент встановлену FTP-сесію, як того вимагає RFC.

¨Отже, сервер (якщо він підтримує такий режим) просто буде намагатись встановити TCP-з’єднання з указаним хостом

¨Це і надає можливість прихованого сканування.

NПослідовність атаки

¨FTP-серверу надсилається команда PORT з IP-адресою і номером порту, який планується перевірити

¨Після цього надсилається команда LIST

¨За цією командою сервер повинен надіслати на об’єкт, визначений командою PORT, список файлів у поточному каталозі