Nатаки на протокол ipv4, що пов’язані з адресацією

¨Підміна адреси відправника (атака IP spoofing)

¨Атака Land

NАтаки, що ґрунтуються на помилках обробки фрагментованих пакетів

¨Перевищення максимально припустимого розміру IP пакета (атака Ping Death)

¨Використання таймауту очікування фрагмента для DOS-атаки

¨Атаки Teardrop і Bonk

¨Фрагментація IP як засіб проникнення через брандмауер

Підміна адреси відправника (атака IP spoofing)

NIP spoofing — це одна з найпростіших і разом з тим найпоширеніших атак

NАтака полягає в тому, що відправник замість своєї вказує деяку іншу IP-адресу

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

NЦя атака компрометує ідентифікацію відправника пакетів за його IP-адресою

nЗастосування IP-spoofing може бути корисним для порушника у багатьох випадках:

¨кінцевий вузол, який піддається атаці, надає певні права доступу деяким машинам, які визначаються за їхніми IP-адресами;

¨міжмережний екран, що стоїть на шляху пакетів, фільтрує їх за IP-адресою відправника;

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

Обмеження атаки IP spoofing

NЗастосовуючи IP spoofing, порушник має значне обмеження: якщо на його пакети повинні надходити відповіді, то він не може їх отримати — вони будуть надсилатись на ту IP-адресу, яка була вказана як адреса відправника у вихідному пакеті

¨Це не є проблемою при використанні дейтаграмних протоколів, таких як

NICMP,

NOSPF,

Nтих, що використовують як транспорт UDP

Nпротокол керування SNMP

Nпротокол служби доменних імен DNS

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

Захист від атаки IP spoofing

NФільтрація пакетів на міжмережному екрані (брандмауері) на вході у захищену мережу дозволяє значно зменшити можливості найбільш небезпечних підмін адрес

¨Типовим правилом є знищення всіх пакетів, які надходять із зовнішньої мережі, але мають зворотну IP-адресу, що належить внутрішній мережі

NТакі пакети є спробою зовнішнього порушника видати себе за легального користувача з внутрішньої (захищеної) мережі

NВикорінення атаки IP-spoofing може бути досягнутим лише за умови контролю за проходженням пакетом певного маршруту

¨Тоді можна буде перевіряти, чи дійсно пакет надійшов звідти, звідки він удає

Атака Land

NАтака Land — це окремий випадок атаки IP- spoofing

¨Атака, незважаючи на її простоту, була здатна призводити у багатьох операційних системах до відмови в обслуговуванні:

nспостерігалось значне навантаження процесора, аж до 100%, а в деяких системах — збої або зависання (UNIX-системи демонстрували “kernel panic”, а Windows — “блакитний екран”)

NСутність атаки полягала в тому, що

¨в IP-пакеті вказувалась IP-адреса жертви і як адреса призначення, і як адреса джерела

¨як транспортний протокол використовувався TCP (це змушувало систему намагатись відповісти на отриманий пакет з метою встановлення з’єднання)

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

NВ результаті система намагалась відповісти собі самій

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

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

NОскільки атака Land відома вже давно, у сучасних системах нештатні ситуації під впливом цієї атаки виникати не повинні.

Атаки, що ґрунтуються на помилках обробки фрагментованих пакетів

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

¨Результатом було зависання комп’ютерів, “kernel panic” у UNIX та Linux, “блакитний екран” у Windows, або перезавантаження

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

Процедура збирання фрагментованих пакетів згідно з RFC 791

nДля того, щоби зібрати фрагменти, модуль IP відбирає дейтаграми, які мають однакові значення чотирьох полів у заголовках:

¨ідентифікатор,

¨адресу джерела,

¨адресу призначення

¨тип протоколу.

nДля збирання пакетів виділяються такі ресурси:

¨буфер даних,

¨буфер заголовка,

¨бітова таблиця блоків фрагментів (один блок = 8 байтів),

¨поле загальної довжини,

¨таймер.

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

¨Таким чином під час збирання відстежується заповнення буфера даних

NВимог до послідовності надходження пакетів не встановлюється.

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

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

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

NМаксимальний розмір IP-пакета становить 65535 байтів разом із заголовком

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

¨При цьому відбувалось переповнення буфера і усі можливі його наслідки

NТакий пакет міг опинитись у буфері завдяки фрагментації пакета

NАтака Ping Death використовувала ехо-запити ICMP (ping)

¨У першому варіанті атаки була запропонована проста маніпуляція з параметром довжини ping-пакета

¨Якщо вказати довжину у 65527 байтів

nкоманда ping –l 65527 victim, де victim — це IP-адреса або доменне ім’я комп’ютера-жертви

¨то загальна довжина IP-пакета буде становити 65555 байтів

Nдо заданої довжини додається 8 байтів заголовка ICMP і 20 байтів заголовка IP

NВже у самому заголовку IPv4 закладена можливість перевищення довжини пакета

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

¨Максимальне значення відповідного поля складає 2¹³–1, а отже максимальне зміщення — (2¹³‑1)*8 = 65528 байтів, що разом із заголовком (щонайменше 20 байтів) вже виходить за межі дозволеного розміру дейтаграми

¨До цього ще треба додати довжину поля даних фрагмента!

nДивно, але в RFC-791 стосовно збирання дейтаграми не згадується перевірка виходу за дозволені межі її розміру, тобто це питання вирішують розробники ОС

Можливість простої DOS-атаки

NВідсутня можливість перевірити, чи всі фрагменти дейтаграми вже надійшли

¨Єдина можлива перевірка — це контроль заповнення “вікон” від початку поля буфера збирання до кінця фрагмента, який позначений, як останній

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

¨Якщо у заголовку фрагмента було встановлено TTL=255, то саме це значення в секундах буде прийнято як тайм-аут

¨Протягом понад чотири хвилини ресурси комп’ютера, включаючи зарезервований буфер, будуть зайнятими!!!

nДостатньо створити два фрагмента:

¨перший будь-якого розміру

¨другий, що помічений як останній, з великим значенням зміщення і TTL=255

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

Атаки Teardrop і Bonk

nФрагмент коду:

¨end = (offset + total_len) — ihl;

¨if (prev!=NULL && offset<prev–>end)
{
i=prev–>end - offset;
offset += i;
ptr += i;
}

¨fp–>offset = offset;
fp–>end = end;
fp–>len = end - offset;

¨memcpy((ptr+fp–>offset), fp–>ptr, fp–>len);