Угроза DoS — обсуждаем уязвимости протокола ICMP

Так, одно из слабых его мест — механизм перенаправления. С его помощью злоумышленники могут управлять маршрутизацией трафика. Разберём, в чем тут дело и как этому можно противодействовать.

Наследие

Протокол ICMP является важным компонентом стека TCP/IP. Он нужен для передачи сообщений об ошибках — например, если целевая служба или хост не могут принять отправленные пакеты. Его также используют ^[2] утилиты для диагностики сети вроде ping или traceroute.

Сам по себе протокол достаточно старый. Его описали в формате RFC792 ^[3] ещё в 1981 году. Неудивительно, что за это время в нем нашли некоторое количество уязвимостей. Например, злоумышленники могут использовать ^[4] ICMP, чтобы установить скрытое соединение с целевым компьютером и передавать данные в обход файрволов.

Буквально в этом году нашли CVE-2023-23415 ^[5] с критическим уровнем опасности. Она открывает возможность удаленного запуска кода в части современных версий Windows. Правда, для этого система должна была иметь приложение, которое слушает «сырые сокеты ^[6]» (raw socket). Уязвимость быстро исправили ^[7] патчем.

Еще одну относительно свежую уязвимость обнаружили члены ассоциации USENIX, занимающиеся изучением Unix-подобных систем. Проблема связана с механизмом перенаправления ICMP.

В чем тут дело

Механизм перенаправления ICMP позволяет управлять маршрутами доставки пакетов в динамическом режиме. Когда маршрутизатор обнаруживает новый оптимальный путь, он генерирует специальное ICMP-сообщение с просьбой обновить таблицу маршрутизации и передает его второй стороне подключения. Команда инженеров из Университета Цинхуа в Пекине показала ^[8], что этот механизм содержит критическую уязвимость.

Хакеры могут использовать набор протоколов, не сохраняющих информацию о состоянии клиента (например, UDP, ICMP, GRE, IPIP и SIT), чтобы сформировать поддельные ICMP-сообщения. Подменяя IP-адрес источника, они получают возможность манипулировать трафиком устройств по своему усмотрению и проводить DoS-атаки.

Как отмечают исследователи, большинство современных операционных систем по умолчанию держат открытыми несколько общеизвестных UDP-портов — например, для NTP, SNMP, DHCP, DNS и TFTP. Злоумышленник может проверить их статус перед отправкой поддельных ICMP-сообщений. Проблема актуальна как для IPv4, так и для IPv6.

По своей сути атака с помощью протокола ICMP чем-то напоминает ARP-poisoning ^[10]. Однако исследователи считают первую более опасной из-за её скрытности. Под угрозой оказались сборки Linux начиная с версии 2.6.20 и новее. Для FreeBSD уязвимость актуальна с версии 8.2, а для Android — с 4.2. Тесты также показали, что более 43 тыс. популярных сайтов в 130 странах мира не защищены от уязвимости. Под ударом могут оказаться и DNS-серверы — 5% из них не защищены.

Но можно ли защититься

Закрыть слабое место в системе можно, если отключить ^[8] ICMP-перенаправления для протоколов без статического состояния — таких как UDP, ICMP, GRE, IPIP и SIT. Но не стоит отключать ^[11] поддержку ICMP полностью, так как это полезный инструмент для диагностики сети и корректной обработки ошибок при передаче пакетов.

Если говорить о долгосрочной перспективе, то резиденты Hacker News в тематическом треде призывают ^[12] внедрять сетевой стандарт безопасности BCP 38. Он был описан еще в 2000 году и запрещает передачу трафика, который не входит в сетевой диапазон интернет-провайдера. Такой подход должен ограничить ^[13] возможности злоумышленников, не позволяя ^[13] проводить масштабные межсетевые DoS-атаки. Однако для его полноценной реализации потребуются общие усилия операторов.

На хосте с IPv4 защититься от атак также можно, если использовать ^[14] 16-разрядное поле ID в связке с SRC-IP, DST-IP и PROTO. Этот метод создаст дополнительный уровень проверки сообщений на подлинность за счёт сравнения идентификаторов по комбинации трёх значений. В теории такой подход можно распространить и на IPv6, только использовать поле flow-id.

Дополнительное чтение в корпоративном блоге VAS Experts:

• Какая уязвимость в протоколе RPL вызывает kernel panic ^[15]

• Потенциальная уязвимость DHCP и rDNS — что нужно знать ^[16]

• «Откуда не ждали»: как IPv6 может скомпрометировать сети ^[17]