ru.nethack

 
 - RU.NETHACK -------------------------------------------------------------------
 From : Andrey Sokolov                       2:5020/400     27 Dec 2004  14:26:35
 To : All
 Subject : о реверсивных троянах -- часть 4, последняя
 -------------------------------------------------------------------------------- 
 

 Hi All,
 
 Путь два с половиной
 (вместо эпиграфа)
 если умный в гору не пойдёт, значит гора пойдёт к Магомету
 Путь номер два с половиной -- это пресловутый svchost.exe. Уютная гавань для
 профессиональных взломщиков. Svchost.exe, которому можно всё.
 
 Hет, никаких внедрений и прочих действий, потенциально способных возбудить
 бдительного и "грамотно защищённого" (с) пользователя! Путь номер два с
 половиной заключается в том, чтобы максимально эффективно и без какой бы то ни
 было суеты брать от системы то, что она сама готова радостно предоставить.
 
 Итак, идея заключается в честном (хоть и немного в лукавом) использовании
 gethostbyname().
 
 gethostbyname() -- это не сокетный слой, как это ни странно. Да,
 юзерспейсовская функция лежит в ws2_32.dll, и мои рассуждения поначалу могут
 показаться несколько сомнительными... но реализует эту функцию служба
 разрешения имён!
 
 Более подробно: любой процесс может сделать gethostbyname(), но отвечать на
 неё (и за неё) будет локальная служба разрешения имён. Отдавать ответ, если он
 уже прокеширован или открывать udp-сокет, задавать non-authoritative-вопрос
 локальному dns-серверу или authoritative-запрос удалённому dns-серверу будет
 служба разрешения имён (то есть, поток svchost.exe)!
 
 Можно поотлаживать на уровне ядра программу nslookup.exe, и увидеть, как на
 самом деле работает служба разрешения имён.
 
 В принципе, человеку сведущему далее становится всё кристалльно ясным и
 понятным. Это идеальная схема -- пусть медленного, но зато очень надёжного --
 способа транспорта данными в обход любых возможных ограничений персонального
 фаерволла. Ибо вряд ли можно представить себе пользователя, который блокирует
 разрешение адреса по имени.
 
 Всё же, я порассуждаю о решении проблемы транспорта на основе gethostbyname().
 
 Схема такова:
 CODE
 клиент на стороне жертвы
 
       |
       |        (подчеркну ещё раз: это соединение дозволено у любого!)
       |
 
 локальный (относительно жертвы) dns-сервер
 
       | \
       |   \
       |     > корневой dns-сервер (скажем, зоны ru)
       |   /
       | /
 
 dns-сервер взломщика (положим, это контроллер зоны hack.ru)
 
       |
       |
       |
 
 управляющая программа взломщика
 Итак, для начала, следует выяснить возможности, которые предоставляет этот
 системный 
 
 вызов: на вход мы даём строчку, разделённую точками, а на выходе мы получаем
 список 
 
 IP-адресов, соответствующих этой строчке. Стало быть, на входе мы даём ответ,
 который должен достичь dns-сервера взломщика (по authoritative-запросу, по
 прямому tcp-соединению между локальным для жертвы dns-сервером и dns-сервером
 взломщику, или по non-authoritative-запросу, через корневой dns-сервер зоны ru
 и далее, по нисходящей, рекурсивно, пока не достигнет dns-сервера взломщика).
 
 Данные от клиента на стороне жертвы кодируются таким образом:
 
 pseudotrash1.pseudotrash2.....pseudotrashN.hack.ru
 
 соответственно, в псевдотрешах закодированы ответы. Клиенту на стороне жертвы
 приходят данные в виде списка IP-адресов:
 
 IP1, IP2, IP3, ..., IPN.
 
 gethostbyname() -- блокирующий системный вызов, и можно воспользоваться его
 асинхронными эквивалентами из WinSock2.
 
 Далее, следует изучить протокол DNS (тут вполне хватит одного rfc1035, так
 как, на этапе анализа проблемы, нас интересует только детали взаимодействия
 dns-клиента и dns-сервера). В частности, изучить формат dns-запросов и
 dns-ответов, выяснив пределы. И эти пределы, к сожалению, весьма тесные (по
 причине ограничения на размер udp-дейтаграммы в протоколе DNS). Кроме того, в
 процессе изучения этих форматов, можно увидеть, что в одном "вопрос-ответе"
 можно закодировать лишь пару сотен байт от жертвы ко взломщику и несколько
 десятков байт от взломщика к жертве. Hо ведь настоящих героев это не
 обламывает, правда?
 
 Кроме того, обязательно отмечу одну возможно неприятную деталь: если локальный
 dns-сервер жертвы настроен таким образом, что блокирует autoritative-запросы
 от жертвы, то придётся воспользоваться более тяжёлым и долгим механизмом
 рекурсивных non-autoritative-запросов. Это значит, что данные будут
 кешироваться во всех dns-серверах, через которых эти запросы будут проходить.
 Эту проблему можно решить, устанавливая низкое время актуальности на
 dns-сервере взломщика, но временные издержки не снизишь по-любому, и время
 прохода одного "вопрос-ответа" может занимать порой до половины секунды!
 
 Возможно, возникнет ещё один вопрос: как сделать этот самый "dns-сервер
 взломщика"? Очень, кстати, просто. Берётся какая-нибудь не слишком свежая
 версия программы bind и пропатчивается. Это не так сложно как может показаться
 на первый взгляд (хотя, изрядная доля смелости и наглости, чтобы превзойти
 страх перед этим занятием, должна присутствовать).
 
 КОHЕЦ
 
 p.s: если кто-то захочет пообщаться со мной на эту тему, добро пожаловать!
 отвечайте прям в этом разделе.
 
 --- ifmail v.2.15dev5.3
  * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор