Перейти до змісту
  • Програмне забезпечення
  • Уязвимость в Tcp


    Рекомендовані повідомлення

    Уязвимость в TCP, подробное описание

     

    Уязвимость, описанная в данном уведомлении, затрагивает реализацию TCP протокола, описанную группой проектирования Internet в технической документации (RFC) для TCP, включая RFC 793 и RFC 1323. TCP - базовый сетевой протокол, в настоящее время используемый в большинстве сетевых компьютерных систем. Многие производители включают поддержку этого протокола в свои программы, которые могут быть в различной степени уязвимы. Кроме того, любые сетевые службы или приложения, опирающиеся на TCP подключения, тоже подвержены нападениям, причем опасность нападения зависит, прежде всего, от продолжительности TCP сеанса. Степень опасности

    Влияние этой уязвимости зависит от производителя и от приложения, но в некоторых случаях оно оценивается как критическое. Для более полной информации см. раздел информации производителей. Дополнительно свяжитесь с производителем вашего программного обеспечения для получения более детальной информации о вашем продукте. При эксплуатации уязвимости у злоумышленника появляется возможность создания условий для отказа в обслуживании (DDoS) существующим TCP подключениям, что приводит к преждевременному завершению сеанса. Завершения сеанса воздействует на уровне приложения, а характер и степень опасности зависят от протокола приложения.

    Пограничный межсетевой протокол (BGP), оценивают как потенциально наиболее подверженный этой уязвимости.

    BGP основывается на устойчивом TCP сеансе между двумя сетевыми узлами. Сброс подключения может привести к недоступности узла в течение времени, необходимого для восстановления таблиц маршрутизации и перестройки маршрута. Перестройка маршрута может привести к недоступности маршрута, если он происходит слишком часто в течение короткого промежутка времени. Однако даже при успешной атаке, воздействие на BGP, вероятно, будет уменьшено в случае использования TCP MD5 сигнатур и антиспуфинговых мероприятий, поскольку они успешно смягчают воздействие уязвимости.

    Имеется потенциальная опасность воздействия уязвимости на другие протоколы приложений типа DNS и SSL в случае зональных передач и транзакций электронной коммерции соответственно, но продолжительность таких сеансов относительно небольшая, и они могут быть без проблем перезапущены. В случае с SSL может быть затруднение с определением исходного IP адреса.

    Возможна также инъекция данных, но это не демонстрировалось и кажется довольно проблематичным.

    Резюме Проблема, описанная в этом уведомлении - возможность сброса установленного TCP подключения с помощью посылки соответствующих TCP пакетов с набором флагов RST или SYN. Пакеты должны иметь IP адреса источника и назначения, соответствующие установленному подключению и те же самые TCP порты источника и назначения.

    Хотя DDoS атака, использующая обработанные TCP пакеты является известным слабым местом в TCP протоколе, но до недавнего времени она считалась практически неосуществимой. Причиной этого является проверка порядкового номера RST или SYN пакета (32-разрядное число), а вероятность правильного определения этого номера равна 1/2^32.

    Исследователем осуществления RST атаки был Пауль Ватсон. Он заметил, что вероятность правильного определения нужного порядкового номера пакета гораздо выше, чем 1/2^32. Это происходит из-за того, что протокол принимает любой порядковый номер в некотором диапазоне (TCP window size) от требуемого числа, что делает реальным выполнение такого вида нападения.

    Любой протокол приложения, основывающийся на долговременном TCP соединении и для которого известны TCP порты и IP адреса источника и назначения будет уязвим, по крайней мере, к DDoS атаке.

    Подробности TCP - протокол транспортного уровня, предназначенный для передачи IP пакетов. Для этого TCP использует наборы флагов, указывающих состояние и порядковые номера для определения порядка реассемблирования пакетов. В TCP протоколе также используется число, называемое номером подтверждения и используемое для указания порядкового номера следующего ожидаемого пакета. Пакеты реассемблируются только в том случае, если разброс их порядковых номеров происходит в пределах диапазона номера подтверждения. Номер подтверждения не используется в RST пакете, потому что при сбросе не ожидается возвратный пакет. (Если быть более точными, то последнее утверждение правильно только для RST пакетов без флага ACK, используемых для указания на закрытие TCP порта. RST/ACK пакет используется для приостановления активного соединения в случае ошибки, и в нем заключен номер подтверждения)

    Размеры TCP window определяются в процессе синхронизации соединения и при этом обычно устанавливаются наиболее высокие значения TCP window, что в некоторых случаях, обеспечивает улучшение производительности. Значения установленные производителем по умолчанию тоже влияют на выборку. В любом случае, чем больше размер TCP window, тем выше вероятность, что случайно выбранный порядковый номер TCP будет лежать в пределах области TCP window. Это и является основой для атаки.

    TCP подключение определяется IP адресами и портами источника и назначения. Злоумышленник пытающийся разорвать существующее соединение должен правильно подобрать все эти значения. И хотя порт источника меняется, однако в представленном исследовании показано, что процесс выбора исходного порта включает в себя предсказуемые элементы, поэтому атака становиться реально осуществимой.

    Протоколы прикладных программ, на которые оказывается критическое воздействие:

    Зависящие от долговременных TCP подключений Имеющие известные или легко определяемые IP адреса назначения Имеющие простой для предположения TCP порт источника Как было отмечено выше, BGP использует долговременные TCP подключения, а IP адрес источника и порт источника иногда доступны в BGP зеркале или в ресурсных записях DNS. Использование команды "trace route“ может предоставить информацию об IP адресах сетевых узлов. Таким образом, данная уязвимость имеет критическое воздействие на BGP. Такие DDoS атаки могут быть выполнены как с одной машины, так и множественными системами (для формирования распределенной DDoS атаки).

    Смягчение последствий Ниже представлены следующие шаги необходимые при отсутствии исправлений у производителя: Внедрение IP защиты (IPSEC), шифрующей трафик на сетевом уровне (при этом становится недоступной TCP информация) Уменьшение размера TCP window (хотя это увеличивает потери трафика и последовательную ретрансляцию) Запрет оглашения информации о TCP порте источника Необходимо отметить, что IPSEC предоставляет секретность информации и службы аутентификации на сетевом уровне и может поддерживать проверку подлинности конечных точек соединения также как и шифрование трафика между ними. Однако в нашем случае IPSEC будет отклонять RST и SYN пакеты, которые не являются частью безопасного потока IP пакетов. Для изменения заданного по умолчанию значения размера TCP window в некоторых Unix системах, вы можете использовать программу “sysctl”. В случае Microsoft Windows NT /2000/XP/2003, заданный по умолчанию размер TCP window может быть изменен, путем модификации значения ключа реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters.

    Как было отмечено выше, следует с осторожностью изменять значение TCP window, т.к. это может привести к большой потере производительности. Ниже приведены действия, которые помогут смягчить проблему в случае с BGP:

    Выполнить входную и выходную фильтрацию. Это необходимо для проверки того, что входящий и исходящий трафик имеет IP адрес источника, ожидаемый на интерфейсе маршрутизатора / брандмауэра принимающего трафик. Выполнить TCP MD5 Signature Option для подсчета контрольной суммы TCP пакетов, несущих данные BGP приложения. (См. RFC 2385). Ограничить количество информации доступной через BGP зеркала и ресурсные записи DNS. Информация производителей Ниже представлен список производителей, предоставивших информацию о воздействии данной уязвимости на их продукты:

    Certicom Check Point Cisco Cray Inc Hitachi Innovaphone Internet Initiative Japan, Inc InterNiche Internet Initiative Japan, Inc InterNiche Juniper Networks Mitel Networks MRLG MRLG NEC Yamaha

    Источник: http://www.uniras.gov.uk/vuls/2004/236929/index.htm

    Посилання на коментар
    Поділитись на інші сайти

    • 3 тижня через...
    ×
    ×
    • Створити...

    Важлива інформація

    Використовуючи цей сайт, Ви погоджуєтеся з нашими Умови використання, Політика конфіденційності, Правила, Ми розмістили cookie-файлы на ваш пристрій, щоб допомогти зробити цей сайт кращим. Ви можете змінити налаштування cookie-файлів, або продовжити без зміни налаштувань..