Многие московские провайдеры подвержены взлому через гостевые входы, в результате чего злоумышленник имеет возможность пользоваться услугами провайдера бесплатно.
В основном используются технологии ICMP Tunneling, а также RTCP.
За последние два месяца было исследовано несколько московских провайдеров, предоставляющих dialup доступ в интернет и использующие систему оплаты по карточкам.
Гостевой вход в идеале дает возможность посетить сайт провайдера для регистрации\пополнения баланса. Реальность как обычно сильно отличается от идеала.
Результаты исследования оказались такими: почти четверть провайдеров выдавала динамический IP-адрес гостю из того же диапазона, что и обычным пользователям (а не локальный адрес), среди которых 50% неправильно настроили фильтрацию трафика от "гостей", и как результат - гость может может обмениваться пакетами специального
вида с любым хостом в глобальной сети. Все провайдеры фильтруют исходящие соединения, т.е. TCP SYN (кроме сайта ISP) - что, как им кажется, полностью блокирует доступ на другие сайты. Многие на этом и успокаиваются. Это дает возможность использовать протоколы прикладного уровня как транспортные протоколы или т.н
TUNNELING. Основной принцип обхода фильтрации - использование промежуточного хоста в сети, оптимальный вариант - root shell на любом unix-сервере.
Попробуем классифицировать способы такого "обхода защиты" по виду используемого транспортного протокола и способу использования промежуточного хоста.
1 способ. ICMP Tunneling. Весьма древний способ, однако против провайдеров применяется видимо впервые. Основывается на предположении, что на уязвимом провайдере проходят in/out icmp пакеты. Обычно IMCP траффик не анализируется и никак не учитывается
назко квалифицированными администраторами. Такая ситуация наблюдалась почти на всех провайдерах, поэтому остановимся на таком способе и рассмотрим его подробно.
Схема протокола выглядит так.
Программное обеспечение на компьютере пользователя
TCP пакеты вкладывает в ICMP пакеты, также туда вкладывается
дополнительная тех. информация, используемая на следующих
этапах (обработка ошибок, поддержка нескольких TCP соединений, адрес:порт хоста
к которому пользовательская программа запросила соединение) и пакет отправляется на промежуточный хост
(ПХ). На ПХ устанавливается программа принимающая icmp пакеты от пользователя. Она извлекает их них TCP пакеты, меняет в них source address и отправляет их на указанный хост:порт, если последний отправляет на ПХ данные в ответ, ПХ упаковывает их в ICMP и не меняя поля source address шлет их пользователю.
В результате создается "виртуальное" TCP соединение, причем как пользовательские программы так и удаленный хост считают, что оно установлено обычным образом. Вся коррекция ошибок при передаче данных (если какие-то пакеты будут потеряны) возлагается на ядро ОС пользователя и ОС удаленного хоста. ПХ и
клиентская программа никак не участвуют в этом. Поддержка нескольких соединений достигается введением дополнительного поля в транспортный протокол (кроме самих данных) и использованием в программе на ПХ кольцевого буфера с сортировкой.
Достоинства:
- Маловероятное обнаружение использования данной схемы самим провайдером.
- Коррекция ошибок самим ядром.
Недостатки:
- Нестабильность и низкая скорость передачи данных в силу специфики протокола ICMP.
- Требуется root shell на ПХ, т.к. нужно перехватывать ICMP пакеты - такая
привилегия дается только root. - Увеличивается нагрузка на канал(по сравнению с номинальной)
из-за вложения одного пакета в другой. Это приводит к "утяжелению" каждого передаваемого пакета.
Вывод - очень удобная схема для совершения незаконных действий в сети не требующих передачи больших объемов данных.
2 способ. RTCP (Reverse TCP) - включен в данную статью
из- за простоты использования и написания. Эта схема является конкурентом предыдущей
из-за возможности передавать данные с намного большей скоростью
(фактически со скоростью самого канала). Однако данную схему можно использовать всего на двух московских провайдерах
из-за очевидного способа использования самой уязвимости - возможность установления входящих соединений на хост пользователя. Такая оплошность со стороны ISP выглядит по меньшей мере странно, однако она имеет место быть, причем
у довольно крупных провайдеров.
Принцип действия. На компьютере пользователя работает
ПО, которое, используя WinAPI, перехватывает все исходящие соединения и переадресует их на локальный порт(назовем его - A), туда же передаются данные о том куда на самом деле пытался подключиться пользователь (в специальном формате) - т.е. похоже на принцип работы SOCKS5 (и еще более похоже на принцип работы небезызвестной программы
SocksCAP). При подключении на порт A, ПО принимает данные о том куда надо подключиться и посылает запрос на ВХОДЯЩЕЕ СОЕДИНЕНИЕ промежуточному хосту и слушает порт
B. Запрос может быть любым пакетом (например TCP ACK
который проходит почти везде или "многострадальный" ICMP).
Главная информация которую он несет - IP отправителя.
Получается "связка" двух серверных сокетов.
ПХ подключается на порт B - принимает через него данные о том куда надо подключиться + некоторое количество данных скопившихся в буфере
клиента после подключения пользовательского ПО на порт А. ПХ подключается на нужный хост:порт. Цепочка замыкается - устанавливается полноценное TCP-соединение в стиле SOCKS-proxy.
Достоинства:
- Полноценное соединение.
- Максимальная скорость передачи данных(ограничивается только каналом).
- Небольшое количество и полная коррекция ошибок.
Недостатки:
- Вполне вероятное обнаружение использования схемы.
- Долгий процесс установления соединения.
- Небольшое количество уязвимых ISP.
Вывод - удобно, просто, быстро, но опасно. Такая схема представляет угрозу только самому провайдеру, т.к. обнаружить человека, подключившегося фактически через SOCKS-прокси довольно легко (логи и пр.)
И еще некоторое дополнение - на всех провайдерах существует уязвимость такого рода:
есть возможность передавать в сеть дискретные исходящие данные делая специальный
DNS запрос на DNS-сервер провайдера. Надо поставить на свой шелл поддельный
DNS-сервер, зарегистрировать любой домен типа domenshella.com, и выдавать
DNS-запросы типа nekaya-informacia.domenshella.com - данные будут приходить на шелл.
Уязвимость не очень важная, хотя найти ей
пользование вполне возможно.
Остальные способы тоже могут использоваться на многих ISP. Все они используют один и
тот же принцип - "игра" с TCP флагами. Например у кого-то проходят TCP SYN RST FIN или что-то в этом роде - соответственно
перехватываем пакет, ставим в нем дополнительные флаги RST FIN - и
отправляем его дальше на ПХ. Тот в свою очередь убирает эти флаги,
меняет source на свой адрес и отправляет куда надо.
Из всего вышеизложенного можно сделать вывод, что большинство московских ISP имеют уязвимости в системах гостевого доступа, что чревато самыми разнообразными, но одинаково негативными последствиями как для самого ISP, так и для других пользователей. Советом администраторам ISP может быть следующее: не следует надеяться на фильтрацию, лучше выдавать гостям локальные адреса, и также следует ограничивать время гостевой сессии 10-ю минутами.
