TCP hijacking

Для ідентифікації TCP-пакета в TCP-заголовку існують два 32-розрядних ідентифікатора, які також грають роль лічильника пакетів — Sequence Number і Acknowledgment Number. У випадку, якщо хост A хоче встановити TCP-з'єднання з хостом B, відбувається т. зв. «потрійне рукостискання», в процесі якого хости обмінюються наступними пакетами:

• хост A посилає хосту B пакет зі встановленим бітом SYN та 32-бітовим значенням ISSa в полі Sequence Number
• хост B відповідає хосту A пакетом із встановленими бітами SYN і ACK, 32-бітовим значенням ISSb в полі Sequence Number, і значенням (ISSa+1) в полі ACK
• хост A відповідає хосту B пакетом з встановленим бітом ACK, значенням (ISSa+1) в полі Sequence Number, і значенням (ISSb+1) в полі ACK.

На цьому пакеті завершується установка з'єднання, тому в наступному пакеті хост A передає хосту B корисну інформацію

• хост A відповідає хосту B пакетом з встановленим бітом ACK, значенням (ISSa+1) в полі Sequence Number, і значенням (ISSb+1) в полі ACK. У цьому пакеті включена вся корисна інформація.

Розглянувши схему установки з'єднання, описану вище, можна помітити, що єдиними ідентифікаторами, за якими кінцевий хост може розрізняти TCP-абонентів та TCP-сполуки, є поля Sequence Number і Acknowledge Number. Таким чином, якщо атакуючий визначить значення ISSa і ISSb для цього з'єднання, то він зможе сформувати помилковий TCP-пакет, який буде сприйнятий та оброблений кінцевим хостом.

Один з видів атаки має на увазі, що атакуючий вбудовує в TCP-пакет контрольний біт RST (Reset). Відповідно до стандарту RFC 793, цей прапор говорить хосту-мішені скинути з'єднання без будь-яких подальших взаємодій. По полю Sequence Number хост-мішень визначає, обробляти або ігнорувати команду скидання, причому мішені заборонено посилати відповідь з встановленим бітом RST. Важливо зауважити, що хост-мішень перевіряє справжність RST запиту лише по Sequence Number, і закриває з'єднання, якщо воно потрапляє в поточне TCP вікно. І, незважаючи на те, що хост-мішень може розрахувати acknowledgment number, він не зобов'язаний цього робити, і, як виявив Paul Watson, більшість стеків TCP просто ігнорують цей крок.

Ухвалений RST пакет завжди приведе до завершення з'єднання. З'єднання, розраховані на тривалий час, наприклад BGP-з'єднання між роутерами, надзвичайно вразливі до таких атак. Насамперед, у нападника буде достатньо часу для впровадження акуратно спланованого пакету, і, з іншого боку, величезні втрати викличе DoS. Роутерам доводиться перенастроювати таблицю сусідів, що може зайняти декілька хвилин в реальних умовах.

Менш очевидний факт, що прапор SYN також може обрушити з'єднання. Згідно RFC 793, коли прапор SYN встановлюється при установці з'єднання, полі Sequence Number містить початкове значення, яке буде використано в подальшому. Якщо згодом по цьому з'єднанню буде прийнятий SYN пакет, RFC 793 буде трактувати це як помилку. Внаслідок чого одержувачу доведеться скасувати з'єднання шляхом посилки RST пакета. На відміну від RST пакету, хост відповість на SYN пакет відправкою RST пакета. Це відкриває можливість ще однієї DoS атаки. Атакуючий згодом може використовувати смугу пропускання жертви. Ця атака особливо успішна в ADSL лініях.

У той час як RST і SYN атаки не використовують корисне навантаження IP-датаграми, третя технологія вбудовує дані в наявне з'єднання. Атакуючий може вставити будь-які дані які приведуть до розриву з'єднання, або акуратно сформувати дані, які приведуть до помилки, або ж будуть виконувати якусь функцію на благо атакуючого. Жертва може навіть не помітити цих маніпуляцій. Наприклад, протоколи FTP і Telnet не перевіряють IP-адреса відправника, і отже при успішному формуванні помилкового TCP-запиту дадуть відповідь на реальний IP-адреса атакуючого, що дозволить повністю перехопити з'єднання.

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

Даний метод ґрунтується на припущенні, що вибір вихідних параметрів ISSa і ISSb (так званого ISN — Initial Sequence Number) при встановленні з'єднання деяким чином залежить від часу. Найкращим з точки зору безпеки був би вибір ISN абсолютно довільним, що зробило б передбачення практично непридатним, однак, в описі протоколу TCP в RFC 793 рекомендується збільшувати значення цього лічильника на 1 кожні 4 мікросекунди, що робить передбачення цього значення тривіальним. На практиці, аналіз вихідного коду старих ядер Linux'а, а також поведінки операційної системи Windows NT 4.0 і молодше підтверджують функціональну залежність обраного значення ISN від часу.

У загальному випадку, при існуванні такої залежності, вона буде виражатися деякою формулою виду ISN = F(mcsec), де mcsec — кількість мікросекунд по апаратним годинах досліджуваної операційної системи.

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

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

Надалі, атакуючому залишається лише стежити за поведінкою досліджуваних хостів, і, обчисливши момент створення з'єднання, приблизно оцінити діапазон обраних хостами значень ISSa і ISSb. Оскільки цей метод є наближеним, то деякого перебору уникнути не вийде, проте математичне моделювання дозволяє на багато порядків (з ~${\displaystyle ~2^{64}}$ до ~${\displaystyle ~100^{2}}$) скоротити кількість пакетів, необхідних атакуючому, щоб провести вдалу атаку.

Однак, не завжди буває можливим провести попередню математичну оцінку значень ISN. Також, в деяких випадках значення вибирається більш-менш незалежно від часу, і, отже, математична оцінка буває ускладнена або неможлива. У такому випадку доводиться вдаватися до більш грубих методів як перебір всіляких значень цих параметрів. Однак, при уважному вивченні стандарту RFC 793, ситуація дещо спрощується.

Перше, що слід згадати — це механізм вікон в TCP протоколі. Пакети при поширенні по Інтернету можуть обганяти один одного. Щоб не втратити прибулі раніше попередників пакети, одержувач встановлює так зване вікно, в якому він може відновити порядок пакетів. Таким чином, якщо значення поля Sequence Number лежить всередині вікна одержувача, протокол TCP прийме та обробить цей пакет. Це значно зменшує кількість спроб, які доведеться зробити атакуючому: воно зменшується з ${\displaystyle ~2^{32}}$ до ${\displaystyle ~2^{32}/windowsize}$.

Залежно від операційної системи, розмір вікна може варіюватися від ${\displaystyle ~65535}$ байт (Windows XP з SP2) і 5840 байт (Linux kernel 2.4 і 2.6).

Вікно зменшить кількість sequence number, яке необхідно використовувати атакуючому. У разі Windows XP це число опускається до ${\displaystyle ~65000}$. Іншими словами, атакуючому доведеться згенерувати лише ${\displaystyle ~65000}$ атакуючих пакетів, щоб ін'ектувати RST пакет і, таким чином, порушити з'єднання. Це дуже маленьке число.

Все стає ще гірше, якщо учасники з'єднання підтримують змінюваний розмір вікна. Ця функція TCP збільшує ймовірність знаходження відповідного sequence number за короткий час. Зміна розміру вікна призначене для сполучень, яким потрібне більше вікно через великі затримки або зайняту смугу пропускання. Щоб дозволити всім передавати без ускладнень, ця технологія розширює розмірність вікна до 14 біт (Microsoft Windows), тобто до ${\displaystyle ~16384}$.

Однак, атакуючому доведеться подолати ще одну перешкоду: четвірку IP-адреса/порт відправника та одержувача. IP адреса навряд чи є проблемою — атакуючий зазвичай знає, на кого він націлюється; також легко визначається порт одержувача. Трохи важче визначити порт відправника, який теоретично може лежати в діапазоні від 0 до 65535. На практиці ж порти нижче 1024 і вище порога, що визначається операційною системою, зарезервовані для спеціальних завдань.

Linux з версією ядра 2.4 або 2.6 використовує як порт відправника числа від ${\displaystyle ~32768}$ до ${\displaystyle ~61000}$.

До задоволення атакуючого, решта ${\displaystyle ~28232}$ варіантів розподілені не випадковим чином; ядро розподіляє їх по конкретній схемі. Таким чином, у атакуючого не виникне особливих проблем з прогнозом порту відправника. Існує лише кілька винятків, наприклад, OpenBSD, яка розподіляє їх довільним чином. Наприклад, Windows XP починає з порту ${\displaystyle ~1050}$ для першого з'єднання, і збільшує порт на 1 для кожного наступного. Linux (Fedora Core 3 з ядром 2.6.9 зокрема) з ${\displaystyle ~32768}$ знову-таки збільшує по порядку. Системи Cisco збільшують значення порту на 512 для кожного нового з'єднання, але це не робить механізм безпечніше.

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