Мережі та інтернет / крок 04
Що не так з Інтернетом в кафе? Розбираємо DHCP
Про що це відео
Ще один епізод серії «як працює інтернет», побудований навколо сценарію з присмаком безпеки: ви сідаєте в кафе, підключаєтеся до Wi-Fi, і ваш ноутбук не має жодних мережевих налаштувань. Поширене припущення — що він запитує налаштування в роутера, але автор наголошує, що «все ще гірше»: у вашого пристрою немає ні IP, ні MAC-адреси роутера, нічого, тож він не може запитати когось конкретного. Він кричить broadcast для всіх: «хто-небудь, дайте мені мережеві налаштування». Відповідь може прийти від роутера або від будь-якої машини в мережі — хтось за сусіднім столиком, запустивши підставний DHCP-сервер на телефоні чи ноутбуці, може підсунути вам зловмисний DNS-сервер (який видає фейкові IP) або зловмисний шлюз за замовчуванням (через який маршрутизується весь ваш незашифрований трафік). Це і є DHCP — Dynamic Host Configuration Protocol — і далі він будує цю атаку наживо.
Головне
- Оскільки клієнт іще не має налаштувань, він не може використати TCP (який потребує handshake до відомого учасника). DHCP їздить поверх UDP broadcast: IP призначення
255.255.255.255(усі біти 1) і MACFF:FF:FF:FF:FF:FF. Broadcast досягає кожного хоста в LAN, але не перетинає роутер (не маршрутизується). - DHCP-трафік розрізняють за портами: сервер слухає на UDP 67, клієнт на 68. Саме порт дозволяє хосту відрізнити DHCP-broadcast від, скажімо, IPTV-multicast.
- Обмін DORA: клієнт розсилає broadcast Discover, сервери відповідають Offer, клієнт обирає один (зазвичай той, чия відповідь прийшла першою) і розсилає broadcast Request із назвою обраного сервера, сервер фіксує прив’язку MAC→IP із часом оренди (lease time) й підтверджує.
- Таймери оновлення оренди: приблизно на 50% оренди (T1) клієнт намагається оновити її напряму з тим самим сервером; якщо не вдалося, на ~87.5% (T2) він знову розсилає broadcast для всіх. Ці значення беруться з RFC і налаштовуються.
- Перегони з підставним сервером і як їх виграти: коли присутні і легітимний, і підставний сервер, чия відповідь прийде першою — питання випадковості. Атакувальнику навіть не потрібно вимикати DHCP на роутері — він просто вичерпує його пул адрес. Він виставив діапазон свого сервера лише на 10 адрес; атакувальник шле ~10 Discover-запитів із різними фейковими MAC, сервер резервує всі 10 для неіснуючих машин, і 11-й реальний клієнт отримує «немає вільних адрес» — тож відповісти може лише підставний сервер.
- Демо наживо: він використовує dnsmasq — крихітний комбінований кешувальний DNS + DHCP-сервер — приблизно з 5 рядками конфігу: upstream
server=8.8.8.8, перевизначення, щобitquiz.comрезолвився на IP Google,dhcp-range, плюсoption:routerтаoption:dns-server, які вказують на його власну машину. Він вимикає DHCP на роутері, задає статичний IP на своєму ПК, потім на планшеті перемикає Wi-Fi і спостерігає у Wireshark (з фільтромdhcp): планшет надсилає Request на свій старий IP, але отримує відмову, бо він змінив його MAC, потім проходить повний цикл Discover/Offer/Request/Ack і отримує його отруєний DNS-сервер. Відкриттяitquiz.comна планшеті приводить на Google із помилкою невідповідності сертифіката (червоне попередження), що доводить: DNS-підміна спрацювала.