Главная
Архив новостей
Безопасность в Unix
Безопасность в Windows
Сборник FAQ'ов
Телефония, фрикинг
Кредитные карты
Криптография
Истории о хакерах
Программы, утилиты
_el@sp.sz.ru

RB2 Network

уязвимость IP_MASQERADING в LINUX


Team Void


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

Кому может понадобиться IP-маскарадинг ? Если у вас есть локальная подсеть и компьютер-гейтвей, если у вашей машины более чем один модем и она работает как PPP или SLIP-сервер, если остальным машинам не назначено IP-адресов (в даннои случае эти хосты представлены ДРУГИМИ), то вы можете применить эту технологию для решения проблемы.

Схематично работа маскарадинга представлена так:

<--к провайдеру--- modem1| маскарадинг |modem2 ---SLIP/PPP----- modem | любой хост | 111.222.333.444 192.168.1.100 Данная схема представляет хост с включённым маскарадингом, который соединяется с Сетью по SLIP/PPP протоколу. У него есть назначенный IP-адрес 111.222.333.444. Когда включён маскарадинг, то modem2 позволяет пользователям дозваниваться на него и устанавливать SLIP/PPP сессии. Вторая система не имеет ассигнованного адреса, а локальный адрес - 192.168.1.100. Но при дозвоне на modem2 с некими исключениями данная машина сможет полноценно использовать TCP/IP протокол.

Естественно, всё гениальное просто - при получении TCP-пакета от хоста 192.168.1.100 маскарадинг модифицирует SRC_ADDR, устанавливает метку, указывающущю на оригинального отправителя, посылает пакет и ждёт ответа.

ПРОБЛЕМА: (рапортовал H. D. Moore /hdm@SECUREAUSTIN.COM/). В связи с проблемами в самом ядре кода masquerading, атакующий способен перезаписать установки маскарадинга UDP, после чего он будет способен организовывать "туннелирующее" UDP-соединения с машиной, находящейся позади хоста, осуществляющего маскарадинг. Атакующий не может знать, какие порты и адреса используются во внутренней сети, то он может вычислить число текужих соединений, идущих через гейтвей и количество хостов, расположенных за файрволом. Любая сеть, где осуществляется маскарадинг UDP-траффика, уязвима для вышеупомянутой атаки (а это - ни много ни мало - DNS, TFTP, NetBIOS, ICQ и большое количество других приложений, использующих протокол UDP).

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

ДЕТАЛИ: IP-иаксарадинг - имплементация NAT (Network Adress Transaction) для систем Linux. Оно позволяет вам подсоединить машину, имеющую закрытый локальный адрес, к интернету более-менее безопасно. Все пакеты, приходящие от "замаскированного" хоста и направленные во внешнюю сеть при прохождении через гейт подвергаются замене обратного адреса на обратный адрес гейтвея и замене порта назначения на порт назначения гейтвея. Это и позволяет подключать сети любого размера к Интернету через один-единственный хост.

Протоколы TCP и UDP требуют, чтобы и порт, с которого отправлен пакет, и порт, на который он отправлен, так же как адрес источника и получателя обязательно присутствовали в пакете. Исходный порт для исходящих соединений обычно выбирается, как первый доступный из диапазона 1024-65535 - а как же выбирает порты гейтвей с установленным маскарадингом ? ядро выбирает порты от 61000 до 65906 по умолчанию, позволяя теоритически обслуживать до 4096 TCP и UDP-сессий одновременно.

Эти значения могут быть изменены путём редактирования и пересборки кода, или же редактированием /proc - файловой системы, через которую можно осуществить доступ к алресному пространству процесса.

Итак теперь, когда соединение, запрошенное внутренним хостом A осуществляется в порта 1025 и его назначение - внешний DNS-сервер Host Z, порт 53, маскирующая машина добавляет новое поле в таблице маскарадинга, быглядещее так:

Host A:1035 (651001) -> Host Z:53

Порт в скобках - это порт гейтвея, с которого оно осуществляет соединение и который использует для коммуникаций с портом 53 хоста Z. А далее мы рассмотрим, как атакующий может перезаписать правую часть данного соединения, чтобы подключиться к порту внутреннего хоста.

Код, отвечающий за UDP masquerading, проверяет только ПОРТ НАЗНАЧЕНИЯ, чтобы определить - пришёл ли пакет из внутренней сети или извне и должен быть переслан внутрь. Затем поля PORT и HOST устанавливаются в исходный адрес и порт отправителя. Атакующему достаточно только определить порт, открытый для соединения на гейтвее, чтобы внести свои модификации в таблицу, перезаписав поля Host Z:53 cвоими данными. Но как определить, что порт из диапазона 65100 - 65096 используется для форвардинга соединений ? Просто, мы посылаем тестовый пакет каждому из этих хостов (гейтвею и внешнему хосту, с которым производится соединение) и просматриваем поле IP_ID в каждом из ответов. Данное поле последовательно увеличивается каждым хостом с каждым посланным пакетом, и ответы от гейтвея будут иметь IP_ID ВНУТРЕННЕГО хоста (это примерно на 1000 меньше, чем IP_ID пакетов, полученных непосрадественно от гейтвея)

ПРИМЕР

Нам известно, что victim.dom поддерживает IP-маскарадинг, а их DNS-сервер вынесен за файрвол. Мы приходим в выводу, что внутренние машины должны обращаться к неймсерверу, чтобы иметь возможность обращаться ко внешним хостам по именам. Итак, мы начинаем посылать наши тестовые пакеты:

Хост A наша внутренная цель (192.168.1.100)
Хост B наш гейтвей (192.168.1.1 / 10.0.0.1)
Хост C - DNS server (10.0.0.25)
Хост X - атакующий (10.10.187.13)


Исполним на гейтвее команду -L -M -n перед тестированием:

> UDP 03:39.21 192.168.1.100 10.0.0.25 1035 (63767) -> 53

[ tcpdump на атакующем хосте ]

[ мы берём порт источника 12345, чтобы наши пакеты было легче отслеживать ]

[ наблюдение за активностью на верхних портах гейтвея >61000 ] 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63762 unreachable [tos 0xd8] (ttl 245, id 13135) 10.10.187.13.12345 > 10.0.0.1.63763: udp 0 (DF) [tos 0x18] (ttl 254, id 23069) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63763 unreachable [tos 0xd8] (ttl 245, id 13136) 10.10.187.13.12345 > 10.0.0.1.63764: udp 0 (DF) [tos 0x18] (ttl 254, id 23070) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63764 unreachable [tos 0xd8] (ttl 245, id 13137) 10.10.187.13.12345 > 10.0.0.1.63765: udp 0 (DF) [tos 0x18] (ttl 254, id 23071) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63765 unreachable [tos 0xd8] (ttl 245, id 13138) 10.10.187.13.12345 > 10.0.0.1.63766: udp 0 (DF) [tos 0x18] (ttl 254, id 23074) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63766 unreachable [tos 0xd8] (ttl 245, id 13139) 10.10.187.13.12345 > 10.0.0.1.63767: udp 0 (DF) [tos 0x18] (ttl 254, id 23083) 10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63767 unreachable [tos 0xd8] (ttl 244, id 17205) Обратите внимание на ID последнего пакета - оно намного больше, чем остальные ID пакетов, возвращённых гейтвеем. Похоже, мы нашли то, что нам требуется! И не окажется большим сюрпризом то, что после просмотра таблицы на гейтвее снова ipchains -L -M -n покажен несколько иной результат:

> UDP 04:35.12 192.168.1.100 10.10.187.13 1035 (63767) -> 12345

Cработало ! У нас появился туннель к порту в общем-то закрытой машины во внутренней подсети.
 duke.


<== Back to main page