УЯЗВИМОСТИ  СЕТЕВОГО  ПРОТОКОЛА  TEREDO

Кокоулин  Андрей  Николаевич

канд.  техн.  наук,  доцент,  Пермского  национального  исследовательского  политехнического  университета, 

РФ,  г.  Пермь

E-mail: 

Андреев  Роман  Александрович

студент,  Пермского  национального  исследовательского  политехнического  университета, 

РФ,  г.  Пермь

E-mail:  

Бадртдинов  Артём  Сергеевич

студент,  Пермского  национального  исследовательского  политехнического  университета, 

РФ,  г.  Пермь

E-mail: 

Феофилова  Полина  Андреевна

студент,  Пермского  национального  исследовательского  политехнического  университета, 

РФ,  г.  Пермь

E-mail:  

VULNERABILITIES  OF  THE  TEREDO  INTERNET  PROTOCOL

Kokoulin  Andrei

candidate  of  technical  sciences,  docent  of  Perm  National  Research  Polytechnic  University

Russia,  Perm

Andreev  Roman

student  of  Perm  National  Research  Polytechnic  University

Russia,  Perm

Badrtdinov  Artem

student  of  Perm  National  Research  Polytechnic  University

Russia,  Perm

Feofilova  Polina

student  of  Perm  National  Research  Polytechnic  University

Russia ,  Perm

АННОТАЦИЯ

В  данной  статье  рассмотрены  различные  уязвимости  сетевого  протокола  Teredo. 

ABSTRACT

This  paper  reviews  the  various  vulnerabilities  of  Internet  Protocol  Teredo.

Ключевые  слова:  Teredo;  сетевой  протокол;  уязвимости.

Keywords:  Teredo;  Internet  Protocol;  vulnerabilities.

Протокол  туннелирования  Teredo  представляет  собой  протокол,  который  обеспечивает  связь  IPv6  через  не  поддерживающие  IPv6  устройства  NAT.  В  Teredo  пакеты  IPv6  инкапсулируются  дважды:  первый  раз  для  инкапсуляции  пакета  IPv6  в  пакет  IPv4  с  установкой  для  поля  протокола  IPv4  значения  41,  а  второй  раз  для  помещения,  полученного  в  результате  пакета  IPv4  в  сообщение  пакета  IPv4  UDP.  Такой  двухэтапный  процесс  инкапсуляции  позволяет  проходить  через  NAT-устройства,  но  оборачивается  значительным  увеличением  накладных  расходов.  Помимо  этого,  туннель  Teredo  также  делает  хост  подверженным  атакам  сканирования,  поскольку  туннельный  адаптер  Teredo,  по  сути,  открывает  порт  на  хосте  для  объектов,  проникающих  через  брандмауэр.  В  результате  этот  порт  может  обнаруживаться  и  подвергаться  атакам.  Поэтому  из-за  увеличения  накладных  расходов  и  проблем  с  безопасностью  протокол  туннелирования  Teredo  должен  применяться  только  в  самом  крайнем  случае.

В  поставляемой  Microsoft  реализации  Teredo  предлагаются  дополнительные  меры  для  защиты  от  атак  сканирования  IPv6,  в  том  числе  и  опция,  позволяющая  указывать,  откуда  разрешено  принимать  трафик:  отовсюду,  кроме  туннеля  Teredo,  отовсюду  и  из  туннеля  Teredo  в  том  числе  или  только  из  локальной  внутренней  сети.  Настройка,  используемая  по  умолчанию,  предотвращает  сканирование  интерфейса  туннеля  Teredo.  Разумеется,  хост  при  этом  все  равно  может  инициировать  передачу  трафика  через  туннель  [1].

Компоненты  Teredo  часто  пересылают  пакеты.  На  самом  деле,  задачей  ретранслятора  и,  в  меньшей  степени,  сервера  является  пересылка  пакетов.  В  следующих  процедурах  Teredo  компоненты  также  создают  новые  пакеты,  основанные  на  непроверенной  информации  во  входящем  пакете.  На  самом  деле,  анти-спуфинговые  меры  не  могут  быть  использованы,  пока  не  получен  ответ.  Итак,  есть  несколько  способов,  которыми  компоненты  Teredo  могут  послать  пакеты  к  третьей  стороне.  Пакеты  могут  перейти  от  IPv4  к  IPv4,  от  IPv4  к  IPv6  и  от  IPv6  к  IPv4.  Эта  возможность  не  новая  в  Интернете;  Например,  поддельные  TCP  SYN  пакеты  часто  получают  ответ,  отправленный  выбранной  третьей  стороне.

Некоторые  атаки  основаны  на  способности  убедить  клиента  Teredo  отправить  один  или  несколько  пакетов  через  интерфейс  Teredo  или,  по  крайней  мере,  создать  запись  в  кэше  последних  одноранговых  узлов  сети  клиента.  Это  не  трудно.  Отправка  клиенту  пакета  с  адресом  источника  Teredo,  который  требует  ответа,  гораздо  более  надежный  способ  создать  запись  кэша  и  формировать  исходящие  пакеты.  Пинг  и  пакеты  IPv6,  которые  генерируют  сообщения  об  ошибках  ICMPv6,  имеют  несколько  вариантов. 

Возможно,  необходимо  послать  несколько  сигнальных  пакетов  перед  отправкой  пакета  от  источника,  что  само  по  себе  может  быть  достаточно,  чтобы  создать  запись  и  сигнал,  который  будет  разослан.  Пакеты  с  адресом  другого,  не  Teredo,  источника  могут  также  служить  для  создания  записи  в  кэше.  От  клиента  зависит,  принять  ли  этот  пакет,  но  клиент  должен  пропинговать  источник,  если  пакет  будет  принят.

Одним  из  способов  для  злоумышленника  убедить  клиента  отправить  несколько  пакетов,  или,  по  крайней  мере,  создать  несколько  записей  в  кэше,  является  многократное  повторение  с  разных  адресов  источника  IPv6.  Другой  подход  заключается  в  использовании  приложений  верхнего  уровня,  таких  как  web  или  email  приложения.  Это  может  привести  к  тому,  что  исходящее  соединение  будет  установлено  с  каждым  из  различных  адресов  IPv6  и  запись  в  кэше  будет  сделана  для  каждого  из  них.  JavaScript  в  HTML  также  может  вызвать  попытки  соединения  со  случайными  адресами  назначения.

В  некоторых  случаях  существование  протокола  Teredo  делает  разработку  эффективных  сетевых  червей  куда  более  легкой.  Основное  преимущество,  которое  черви  могут  получить  от  Teredo,  заключается  в  том,  что  он  обеспечивает  средства  обхода  NAT-устройств.  Это  особенно  верно  для  основанных  на  IPv6  червей,  которые  могут  достигать  IPv6  узлы,  даже  если  устройства  NAT  ограничивает  услуги  IPv6.  Тем  не  менее,  предполагается,  что  все  узлы  будут  иметь  прямую  связь  по  протоколу  IPv6  в  конечном  итоге,  так  что  Teredo  не  может  быть  обвинен  в  уменьшении  сроков  для  данной  возможности.

Даже  с  IPv4,  Teredo,  как  правило,  оставляет  открытым  преобразование  портов  UDP  в  NAT,  так,  что  NAT  будет  перенаправлять  пакеты  к  встроенному  хосту  через  этот  порт,  по  крайней  мере,  от  конкретных  адресов  источника.  Такие  пакеты  достигнут  сервисный  порт  Teredo,  который  может  решить,  какие  пакеты  полезны. 

Даже  если  брандмауэр  хоста  обычно  блокирует  IPv6  пакеты,  существуют  некоторые  слабые  места.  В  частности,  если  есть  уязвимость  в  службе  Teredo  или  в  любом  другом  процессе,  который  выполняется  прежде,  чем  брандмауэр  принимает  решение,  то  это  делает  возможным  удаленное  выполнение  кода,  что,  в  свою  очередь,  позволяет  создать  червя,  похожего  на  Slammer-червя.  Такие  черви  устраивают  DoS-атаки  и  сильно  замедляют  скорость  работы  Интернет-соединения,  при  этом  они  могут  содержаться  в  одном  UDP-пакете,  а  так  же,  в  отличие  от  простых  Slammer-червей,  могут  обходить  NAT.

Хотя  IPv4-черви,  использующие  метод  слепого  поиска  не  могут  извлечь  особой  выгоды  из  использования  уязвимостей  Teredo,  IPv6-черви,  использующие  тот  же  метод,  уже  могут  использовать  уязвимости  протокола.  Сканирование  адресов  Teredo  может  сделать  возможным  сканирование  адресов  IPv6.  Желание  проникнуть  внутрь  NAT  или  необходимость  использования  IPv6  могут  обеспечить  достаточные  основания  для  того,  чтобы  попробовать  осуществить  это  [2].

На  рисунке  1  мы  видим  пример  случая  de-perimeterization.  В  информационной  безопасности  de-perimeterisation  —  удаление  границы  между  организацией  и  внешним  миром.  De-perimeterisation  защищает  системы  организации  и  данные  на  многократных  уровнях  при  помощи  смеси  шифрования,  безопасных  компьютерных  протоколов,  безопасных  компьютерных  систем  и  идентификации  уровня  данных.  Успешное  внедрение  стратегии  de-perimeterisation  в  организации  подразумевает,  что  периметр  или  внешняя  граница  безопасности  была  удалена,  когда  клиент  двойного  стека  устанавливает  поддерживающее  IPv6  приложение,  такое  как  µTorrent  или  Microsoft  Meeting  Space,  на  операционной  системе  Windows.  Такие  приложения  включают  IPv6  (даже  если  он  был  отключен  администратором),  и  настраивают  динамический  туннель  Teredo.  Если  политика  безопасности  IPv4  в  брандмауэре  периметра  разрешает  исходящий  трафик  UDP,  динамический  туннель  Teredo  создается  от  клиента  интранет  к  серверу  IPv6  через  ретранслятор  Teredo.

Рисунок  1.  Создание  туннеля  Teredo

На  рисунке  2  мы  видим  что,  как  только  этот  туннель  создан,  у  него  появляется  побочный  эффект  разрешения  любому  IPv6-злоумышленнику  снова  использовать  тот  же  самый  туннель,  чтобы  напасть  на  внутреннего  клиента.  Если  это  нападение  успешно,  клиентом  теперь  управляет  злоумышленник,  который  может  начать  нападать  на  внутреннюю  часть  организации  по  IPv4  [3].

Рисунок  2.  Пример  использования  уязвимости  туннеля  Teredo

Существует  возможность  для  управления  безопасностью  клиента  Teredo  за  пределами  туннеля.  Это  необходимо,  так  как  Teredo  размещает  клиента  непосредственно  в  Интернете  (любой  узел  IPv6  может  отправить  пакеты,  которые  достигнут  клиента).  Teredo  также  позволяет  незапрашиваемым  входящим  пакетам  быть  переданными  через  туннель.  Таким  образом,  такая  сквозная  связь  будет  нормой  для  IPv6,  но,  несмотря  на  это,  нужно  применять  средства  управления  безопасностью.

Список  литературы:

1. Microsoft.  “Teredo  Overview”  [Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/teredo.mspx,  дата  обращения:  18.04.2015.
2. Symantec.  Symantec  Internet  Security  Threat  Report:  Trends  for  January  06–June  06.  Symantec  whitepaper,  Volume  X,  Sept  2006  [Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://www.symantec.com/specprog/threatreport/entwhitepaper_symantec_internet_security_threat_report_x_09_2006.en-us.pdf  ,  дата  обращения:  28.04.2015.
3. Why  Should  You  Care  about  IPv6  Security?  [Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://www.cisco.com/web/services/news/ts_newsletter/tech/chalktalk/archives/200902.html,  дата  обращения:  10.05.2015.