Безпека поширених прикладних мережевих протоколів погляд з боку клієнта, J3qx

Помилки рівня стандарту - дірки в RFC.

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

Історія протоколу FTP Переходимо до обов'язкової програми. Говорячи про безпеку мережевих протоколів, не можна не розповісти про протокол FTP (File Transfer Protocol, протокол передачі файлів). Останній стандарт, що описує протокол FTP, RFC 959, відноситься аж до 1985 року. Тобто за 3 роки до хробака Морріса — першої події, яка привернула спільну увагу до питань комп'ютерної безпеки. Черв'як Морріса взагалі був хорошим стусаном мережі, що змінив напрямок її розвитку, його користь багаторазово перевершує завдані їм збитки. Але тоді FTP був створений виключно для зручної передачі файлів між системами, але без найменшої спроби зробити цю передачу безпечною. Мене просто вражає той факт, що цей протокол досі використовується, причому практично у первозданній формі, у тих додатках, для яких він не підходить. Протокол FTP взагалі дуже незручний у реалізації — цей протокол ніколи не створювався для реалізації будь-якої клієнтської програми. Наприклад, FTP не визначає формат, у якому має видаватися список файлів. Протокол FTP створювався як розширення стандартного протоколу telnet, тобто. всі команди FTP повинні були даватися користувачем з командного рядка і мав на увазі наявність у користувача shell доступу на сервер FTP. FTP-клієнти, які б надавали користувачеві зручний інтерфейс з'явилися значно пізніше. Давайте коротко опишемо цей протокол. Протокол FTP підтримує 2режиму - пасивний і активний і використовується для передачі файлів (отримання або зберігання) а також отримання змісту каталогів. В обох режимах FTP використовується контрольне з'єднання, яке встановлюється клієнтом на 21-й (за замовчуванням) порт FTP сервера. По контрольному з'єднанню жодні дані, ні файли, ні зміст каталогів, не передаються. Для передачі будь-якого файлу або змісту встановлюється окреме з'єднання.

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

Для цього клієнт міг встановити контрольне з'єднання на сервер A, дати команду PASV, встановити з'єднання на сервер B і дати йому команду PORT з даними переданими сервером A у відповідь на команду PASV. Таким чином DATA connection встановлювалося між серверами A і B, після чого клієнт може дати команду зберігання файлу одному серверу і передачу файлу другому серверу.

Класичні атаки на FTP На перший погляд, все геніально. Недоліки протоколу FTP вперше були докладно описані експертом лабораторії NAI Девідом Сейсердотом (David Sacerdote) лише 1996 року. У чому вони полягають? Що, якщо сервер відкрив порт за командою PASV, до нього підключиться хтось сторонній? Це означає, що коли клієнт дасть команду на отримання чи зберігання файлу, сервер віддасть файлстороннього, або отримає файл люб'язно наданий стороннім, а клієнт залишиться ні з чим. Така ситуація називається перехопленням з'єднання даних (DATA connection hijack).

Як сторонній може дізнатися порт, призначений сервером, якщо не бачив відповіді на команду PASV у контрольному з'єднанні? Для цього йому можливо достатньо встановити своє контрольне з'єднання і дати команду PASV. У більшості випадків, якщо він зробить це безпосередньо перед з'єднанням клієнта, він отримає порт на один і нижче і може спробувати атакувати наступний порт. Наступна класична атака з використанням особливостей протоколу FTP пов'язана з командою PORT.

Що якщо попросити FTP Сервер підключитися до порту стороннього комп'ютера, що цікавить нас? Якщо порт закритий, ми одразу отримаємо повідомлення про помилку. А якщо порт відкрито? Ми можемо заслати туди будь-який файл, що зберігається на FTP сервері, давши команду на отримання файлу. Таким чином, ми можемо використовувати FTP сервер для атак на чужий комп'ютер, залишаючись у тіні. Причому, якщо FTP сервер стоїть на прикордонному комп'ютері, ми можемо атакувати комп'ютер, що знаходиться у внутрішній мережі. Така техніка називається FTP bounce attack (не знаю, як це заведено перекладати українською, але звучить як «атака рикошетом від FTP»).

Ну а що ж з FTP клієнтом? Всі класичні атаки FTP стосуються сервера. Девід Сейсердот написав, що атака на перехоплення з'єднання украй складно реалізується для сервера і не реалізується для клієнта. На жаль, статтю Девіда, за рекомендацією Aleph One, я прочитав значно пізніше: Але не читали її і розробники серверів FTP. А тому, коли років через 5 я винайшов велосипед і знову «відкрив» цю проблему все було в первозданному вигляді. За щасливим збігом обставин ічерез природну лінощі, замість статті я написав дуже просту утилітку, ftpspy, яка використовувала звичайний connection flood успішно спрацьовувала з ймовірністю більше 50% на більшості FTP серверів, що жили тоді. А так само і FTP клієнтів, тільки не в пасивному, а активному режимі.

Отже, ми тепер знаємо основні недоліки FTP з погляду клієнта – можливість перехоплення даних, недостатня стандартизованість та погана сумісність із брандмауерами. Це саме собою вже достатній привід уникати використання FTP скрізь, де можна.

Цей сервер підтримує автентифікацію за методом LOGIN (відкритим паролем), NTLM та GSSAPI. Протокол HTTP (діючий стандарт RFC 2616) визначає можливість аутентифікації користувача, але не дає будь-яких конкретних механізмів. RFC 2617 визначає можливість аутентифікації паролем у відкритому тексті, звану в HTTP Basic або за методом запит/відповідь (challenge/response) який у HTTP називається Digest. Однак автентифікація паролем у відкритому вигляді на сьогодні є єдиним методом, що підтримується у всіх поширених браузерах і веб-серверах. Методи аутентифікації, що підтримуються сервером, видно з заголовка WWW-Authenticate, який сервер дає при запиті на аутентифікацію:

Показує, що сервер підтримує автентифікацію Basic, Negotiate та NTLM.

Протокол FTP підтримує виключно аутентифікацію у відкритому тексті, хоча і для нього є розширення, аналогічні AUTH в SMTP для аутентифікації методом запит-відповідь. Протокол POP3 (RFC 1939) підтримує 2 методи аутентифікації - аутентифікацію у відкритому тексті та аутентифікацію APOP за методом запит-відповідь. Крім того, знову ж таки є розширення аналогічні AUTH в SMTP. Відрізнити сервер підтримує APOP досить легкобанера сервера: +OK Microsoft Exchange Server 2003 POP3 server version 6.5.7226.0 Цей сервер не підтримує APOP. +OK 3APA3A/POP3-2.0-RC5.1

Цей сервер підтримує APOP, що видно щодо привітання укладеної в кутові дужки. Ця частина вітання використовується в APOP як запит (challenge).

Дещо складніше за допомогою розширеної аутентифікації за методами AUTH. Її наявність та дозволені методи іноді можна перевірити за допомогою команд CAPA або команди AUTH без параметрів. Що являє собою кожен метод парольної аутентифікації та які його недоліки?

Аутентифікація у відкритому тексті (plain text, він USER/PASS в FTP і POP3, він же AUTH LOGIN в SMTP і IMAP, він же Basic в HTTP) Недоліки методу очевидні: пароль передається «по проводам» у відкритому тексті, і може бути перехоплений у разі прослуховуваної мережі, що розділяється, за допомогою ARP poisoning, DNS poisoning, при компрометації сервера або іншими методами, обговорення яких виходить за рамки статті. У разі SMTP та HTTP логін та пароль передаються в кодуванні base64.

Аутентифікації за Challenge-Response (запит-відповідь) за допомогою стандартних хеш-функцій До цих методів можна віднести APOP, AUTH CRAM-MD5 та Digest в HTTP, рідше використовуються інші CRAM-методи, наприклад CRAM -MD4, CRAM-SHA1. При використанні такої автентифікації пароль користувача ніколи не потрапляє у дроти. Причому навіть криптографічні проблеми SHA-1 чи слабкі генератори випадкових чисел при генерації challenge мало позначаються лише на рівні захисту пароля. Однак, слід пам'ятати, що Challenge-Response не захищає від атак на підбір слабких паролів (bruteforce), якщо пароль короткий або підбирається за словником.

Вбудована автентифікація Windows ЦеAUTH NTLM і аутентифікації NTLM і Negotiate в HTTP. В Outlook Express вбудована автентифікація NTLM називається SPA (Secure Password Authentication). Недоліки такої автентифікації по-перше в її прозорості — спочатку пробується ім'я та пароль з якими здійснено вхід до системи, по-друге, у багатьох версіях Windows, неможливість підключитися до одного сервера з кількома обліковими записами. По-третє, це можливість атак релеїнгу аутентифікації у разі NTLM. Про цей клас атак та інші особливості та недоліки NTLM докладно розповідається в моїй статті «NTLM та корпоративні мережі»

[http://www.security.nnov.ru/articles/ntlm]. Використовувати вбудовану автентифікацію Windows (і зокрема SPA) з недовіреними серверами в жодному разі не можна.

У багатьох випадках клієнтська програма самостійно вибирає найбільш «потужний» протокол аутентифікації, так чинять, наприклад, практично всі клієнти HTTP (браузери). Хоча бувають і прикрі непорозуміння, як, наприклад, у Mozilla Firefox [http://www.security.nnov.ru/Fnews19.html]. На перший погляд, така поведінка цілком виправдана, але має величезний недолік — атакуючий, який має можливість контролювати трафік між клієнтом і сервером (активні атаки Man-in-the-Middle, наприклад у разі заміни сервера або релеїнгу з'єднання) може «змусити» переповзти клієнта більш м'який протокол аутентифікації, до відкритого тексту.

Зрозуміло, після всього перерахованого вище можна порекомендувати в клієнтському додатку використовувати Kerberos автентифікацію, або, якщо вона недоступна, аутентифікацію Challenge-Response. Крім того, всі сучасні протоколи підтримують TLS (Transport Layer Security, протокол, що поглинув SSL) версію. За умови, що робота зсертифікатами реалізована не коректна, TLS забезпечує надійний захист даних від перехоплення та підміни, а також взаємну автентифікацію клієнта та сервера на основі сертифікатів. Якщо є така можливість, TLS треба впроваджувати і використовувати.Помилки реалізації мережевих протоколів у клієнтських додатках

Хоча це й могло бути смачним, ми не будемо докладно розбирати вразливості конкретних реалізацій. На момент написання статті в базі уразливостей [http://www.security.nnov.ru/] 577 клієнтських помилок (понад 10%). Назвемо найбільш повторювані проблеми:

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

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

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

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

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

Час зробити висновки: необхідно враховувати багато аспектів безпеки клієнтськихдодатків — безпека самого протоколу передачі даних, безпека обраного методу аутентифікації та шифрування, якість коду клієнтської програми. Будь-яке звернення клієнтської програми на сервер пов'язане з деяким обміном даних, ці дані можуть бути «хорошими» або «поганими», про що часто забувають розробники.

---