Уязвимости основных сетевых протоколов

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

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

Наследие

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

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

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

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

В чем тут дело

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

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

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

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

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

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

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

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

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

Источник

HTTP-протокол: уязвимость и риски безопасности

HTTP (HyperText Transfer Protocol) — это универсальный протокол передачи данных через интернет. Изначально он предназначался для отправки гипертекстовых документов, но его современные версии работают практически с любым видом информации: изображениями, видео, аудио и др. Простыми словами, это набор правил, по которым происходит обмен данными между клиентом (браузером пользователя) и сервером, обслуживающим сайт. Его используют все веб-приложения и веб-сайты в интернете, однако HTTP-протокол нельзя назвать безопасным. Иногда он и вовсе оказывает вредное влияние на продвижение. Мы расскажем, в чем риски HTTP, как он работает, и объясним, в каких случаях переход на HTTPS обязателен.

Как работает HyperText Transfer Protocol

HTTP-протокол функционирует поверх стека протоколов TCP/IP, составляющих основу интернета. По модели OSI он является протоколом прикладного уровня (седьмого).

Как мы уже сказали, в работе http участвуют две стороны: клиент и сервер. В роли первого выступает приложение на устройстве пользователя (как правило, это веб-браузер). Оно формирует http-запрос и посылает его на сервер, где размещена информация об искомых сайте или службе. Программное обеспечение на веб-сервере, в свою очередь, обрабатывает этот запрос и выдает http-ответ. Он отправляет его обратно клиенту, браузер интерпретирует данные и отображает их на экране. Вместе это называется http-сообщением. Оно происходит каждый раз, когда вы открываете ссылку, вводите информацию в формы и т. п. — в общем, когда пакеты данных передаются между клиентом и сервером.

Запрос всегда посылает клиент, сервер только отвечает. По стандарту HTTP-запрос состоит из трех частей:

• стартовой строки, задающей параметры запроса и ответа;
• заголовка (их может быть несколько), описывающего служебную информацию;
• тела (его может не быть вовсе), содержащего сами передаваемые данные.

Иногда запрос может включать в себя всего две строки: стартовую и обязательный заголовок Host. Первая составляется по формуле Метод + URI + HTTP/Версия. Метод меняет значения в зависимости от цели запроса (GET — получить, POST — отправить, DELETE — удалить и др.). В URI (Uniform Resource Identifier) указывается путь до конкретной страницы веб-ресурса (через слэш) или звездочка, если запрос обращается к самому веб-серверу. В конце, соответственно, пишется протокол и используемая версия. Заголовок Host является необходимым, поскольку в нем содержится URL-адрес сайта, т. е. информация о местонахождении сервера.

HTTP-ответ строится примерно по той же схеме. В стартовую строку входят HTTP/Версия + Код состояния + Пояснение. Код состояния отражает статус запроса в числовом обозначении (например, 404), а пояснение кратко описывает его суть (например, Not Found). Далее следуют заголовки и тело ответа (в нашем примере это будет HTML-документ страницы 404-ошибки).

По такому принципу строится связь почти со всеми веб-ресурсами в сети. Протокол позволяет быстро передавать любую информацию, но обладает серьезными уязвимостями в безопасности. Ниже мы расскажем, в чем именно состоит риск использования «голого» HTTP без какой-либо защиты.

Опасность использования HTTP

Протокол разработали более тридцати лет назад, когда вопрос о безопасности еще не стоял так остро — важнее было найти универсальный способ передачи информации по глобальной сети. В связи с этим http содержит много уязвимостей, используя которые, злоумышленники могут взламывать серверы, перехватывать данные и проводить другие атаки. Особенно это опасно при передаче конфиденциальных и персональных сведений: платежных данных покупателей, имен и контактов, логинов, паролей и т. д. Главная уязвимость заключается в том, что при http информация передается в открытом виде, без использования шифрования. Другими словами, если на одном из узлов маршрутизации данные будут перехвачены, хакер сможет легко их прочесть. В чем опасность такого перехвата, думаем, понятно. Это основная причина, по которой сайты отказываются от HTTP-протокола, но не единственная.

Помимо риска утечки, существует вероятность того, что злоумышленник, наоборот, добавит лишнюю информацию в передаваемый пакет данных. Это могут быть фрагменты вредоносного кода, которые приведут к нежелательным последствиям: заражению сервера или пользовательского устройства вирусом, DoS-атаке на веб-сайт, подделке оригинального ресурса на фишинговый, межсайтовому скриптингу (XSS) и пр. Уязвимость HTTP дает хакерам простор для действий. Кроме того, применение протокола плохо влияет на посещаемость веб-ресурса и его продвижение в поисковых системах. Все популярные браузеры оповещают пользователей, если соединение с сайтом устанавливается по http: появляется предупреждение о «незащищенном подключении». Некоторые антивирусы и вовсе блокируют переход к таким страницам. Поисковики тоже считают их опасными, и потому при ранжировании отдают предпочтение ресурсам с HTTPS (о нем мы скажем позже).

В следующих параграфах мы перечислили еще несколько проблем, к которым может привести уязвимость HTTP-протокола.

Безопасность и логи HTTP-сервера

Так же, как ваш браузер сохраняет историю посещений, сервер ведет журнал запросов. Это называется логированием. Все записывается в логи — специальный файл, где хранится информация о том, что и когда происходило, кто и зачем обращался, какой ответ был отправлен. В логах веб-сервера могут содержаться данные, представляющие интерес для злоумышленников. Незащищенность http позволяет получить к ним доступ. Чтобы устранить эту уязвимость, нужно обеспечить безопасность журнала HTTP-запросов.

Безопасность передачи данных в HTTP

По HTTP-протоколу можно пересылать любую информацию, но опасность в том, что нет никаких средств для регулирования содержимого HTTP-сообщений. Некоторые поля заголовка (Server, Via, Referer, From) считаются небезопасными, поскольку содержат названия и версии программ, используемых клиентом или сервером. В перспективе это позволяет злоумышленникам воспользоваться уязвимостями клиентского или серверного ПО, что опасно, поскольку на нем лежит функция защиты данных при http-передаче.

Подмена DNS-адресов и HTTP-протокол

ДНС-серверы являются важной частью интернет-архитектуры. Они хранят таблицы соответствий доменных имен и IP-адресов, т. е. буквально представляют собой «телефонную книгу» интернета. Браузер обращается к ним всякий раз, когда нужно узнать айпи-адрес определенного сайта. Уязвимость HTTP-протокола допускает вмешательство в содержимое пакета данных, и потому существует вероятность, что хакер подменит настоящий айпишник запрашиваемого домена на поддельный. В результате браузер посылает запрос на мошеннический ресурс, который может быть полным клоном настоящего.

Стоит ли переходить на HTTPS

Сам по себе HTTP не предусматривает каких-либо механизмов защиты. Но в совокупности с криптографическим протоколом SSL/TLS (Secure Sockets Layer / Transport Layer Security) процесс передачи становится менее опасным. Такое расширение называется HTTPS. Оно устраняет основную уязвимость http, а именно отсутствие шифрования. Для этого на сервер устанавливается SSL-сертификат — некое подобие удостоверения, которое содержит в себе ключи для шифровки данных. Он позволяет шифровать передаваемую информацию и тем самым защищает ее от перехвата. Вернее, от прочтения хакером. Даже если он перехватит пакет, в нем будет виден лишь набор «случайных» символов, для расшифровки которых потребуется ключ. А он есть только у веб-сервера.

Строго говоря, переходить на HTTPS рекомендуется всем сайтам. Помимо уменьшения уязвимостей, это оказывает положительное влияние на доверие пользователей и поисковых роботов. SSL-сертификат является обязательным требованием для ресурсов, работающих с персональными данными и особенно — с сервисами банковского эквайринга. Получить его можно даже бесплатно, поэтому проблем с внедрением возникнуть не должно. Использовать HTTP-протокол допустимо только для статичных веб-ресурсов, которые не собирают информацию от пользователей и сами не содержат ценных данных, а также для локальных сетей с фаерволом.

Заключение

HTTP-протокол представляет опасность, поскольку передает все «открытым текстом», используя только стандартную кодировку, без труда переводимую любым специалистом. Теперь вы знаете, как эта уязвимость может повлиять на работу ваших сайта и сервера и как можно ее устранить. Надеемся, наша статья была для вас полезной.

Источник