Главная страница


ru.nethack

 
 - RU.NETHACK -------------------------------------------------------------------
 From : Andrey Sokolov                       2:5020/400     27 Dec 2004  14:24:00
 To : All
 Subject : о реверсивных троянах -- часть 2
 -------------------------------------------------------------------------------- 
 
 Hi All,
 
 Путь первый
 
 В вопросе реализации транспорта для реверсивной троянской программы, следует
 направить основные усилия на борьбу с основным противником, персональным
 фаерволлом. А персональный фаерволл нынче умеет (и на "грамотно защищённых"
 (с) пользовательских компьютерах, всенепременно делает) следующее:
 
 1) Запрет на любве входящие tcp-соединения. Запрет на приём входящих
 udp-дейтаграмм, если udp-порт назначения во входящем IP-пакете не
 соответствует открытому системой;
 
 2) Возможный запрет на трафик нетранспортных протоколов: начиная от сообщений
 ICMP echo request (в простонародии именуемых "пингами"), заканчивая любым
 произвольным значением поля Protocol в заголовке IP;
 
 3) Запрет на любые исходящие соединения от недозволенных процессов (различной
 тщательности реализации. типовое "правильное" решение проблемы: привязка не к
 названию процесса, а к оригинальному этому процессу файлу)
 
 4) Запрет на любые исходящие соединения от дозволенных процессов, но к
 недозволенным IP-адресам.
 
 Запреты 1-3 реализуются на "грамотно защищённых" (с) рабочих местах
 повсеместно. А вот четвёртый пункт чреват излишним геморроем пользователю:
 вряд ли кому-нибудь понравится изо дня в день отвечать на вопросы фаерволла о
 каждом исходящем соединении в новое место. (Хотя, я знаю одного человека,
 который не отключает эту опцию месяцами).
 
 Итак, метод, который я рассмотрю в "пути номер один", иллюстрирует один из
 способов реализации транспорта для трояна: обход пунктов 1-3 в надежде на
 отсутствие пункта 4.
 
 Без затяжных размусоливаний, опишу детали реализации транспорта в этом случае.
 Замечу, что вариантов может быть бесчисленное множество, и я опишу наиболее,
 на мой взгляд, простой и удобный в реализации и использовании.
 
 0) За основу берётся HTTP. Стало быть, где-то в Интернете имеется некий
 веб-сервер, у которого есть два скрипта.
 
 Первый скрипт обменивается данными с экземпляром клиентской части у жертвы. 
 
 Клиентская часть жертвы эпизодически соединяется с этим скриптом и метод GET
 принимает команды от взломщика. При следующем соединении со скриптом, методом
 POST на сервер отправляются результаты выполнения команды.
 
 Взломщик взаимодействует с сервером через второй скрипт с интерфейсом, удобным
 для нагрузки командами и для получения результатов их выполнения.
 
 1) Изыскивается программа, которой позволительно ходить в Интернет. В ряде
 случаев, такими изысканиями заниматься вовсе не обременительно: если уж кто и
 может ходить в Интернет, так это Его Величество Internet Explorer. 
 
 Можно заморочиться поиском альтернативных броузеров (Mozilla, Opera и
 какие-нибудь более экзотические решения с поддержкой антиальясных шрифтов,
 например) и ходить к скрипту через них. 
 
 2) Прочитывается книга "Windows для профессионалов" Джеффри Рихтера, откуда
 почерпывается способ внедрения потока в произвольный процесс. Да, это самый
 надёжный, в данном случае, способ: делать CreateRemoteThread() в пространстве
 процесса Internet Explorer'а.
 
 Потоки можно внедрять как в уже существующие процессы (в таком случае, троян
 будет отвечать лишь тогда, когда запущен броузер), так и во вновь создаваемые
 процессы, самостоятельно, трояном (в таком случае, троян отвечает всегда,
 когда есть доступ до скрипта).
 
 Сделаю шаг в сторону и расскажу немного о процессах.
 
 Известно, что процессы замечательной операционной системой MS R Windows R не
 исполняются. Грубо говоря, процесс -- это... скажем так, набор данных о
 выполняющихся внутри этого процесса потоков, набор дескрипторов и всевозможных
 статистических и полезных параметров, это динамическая куча процесса и
 всевозможные другие данные, загруженные из соответствующих сегментов
 соответствующего бинарника. А исполняются потоки (или нулевой поток процесса,
 если потоков как бы нет). И потоки имеют доступ ко всем данным (и даже к
 стекам) других потоков: такова архитектура операционной системы.
 
 Итак, поток, присоединяемый к процессу броузера, осуществляет транспортную
 функцию:
 
 -- получает кусок данных, который нужно отправить (это можно сделать массой
 всевозможных способов, часть которых можно почерпнуть из той же книги, из
 раздела о межпроцессных взаимодействиях);
 
 -- соединяется со скриптом посредством нескольких компактных функций из
 wininet.dll (экспортная таблица которой идёт либо вкомпилированной во
 внедряемую dll, либо берётся и разыменовывается из BSS процесса самого
 Internet Explorer'а, если внедряется не dll, а код);
 
 -- если используется прокси-сервис (пусть даже с авторизацией), то все
 настройки (в том числе и пароли авторизации) извлекаются функциями wininet.dll
 автоматом. эта часть не очень хорошо документирована самим микросовтом, однако
 в зинесе A29 можно прочитать об этом статью;
 
 -- делает GET, чтобы получить новости;
 
 -- делает POST, и отправляет кусок данных, предназначенных к отправке;
 
 -- если есть новости, отдаёт кусок полученных данных в процесс трояна;
 
 -- самоуничтожается.
 
 Если троян осуществляет выполнение парочки простых внутренних функций (типа
 самоуничтожения или изменения задержки перед следующим коннектом) и
 переброской команд интерпретатору cmd.exe, итоговый троян (прописыватель,
 внедряющий троян в систему, сам троян и транспортная dll) получаются очень
 лёгкими, вряд ли больше 40-50 килобайт.
 
 Итак, налицо простая и вполне рабочая (при условии отсутствия четвёртого
 пункта) схема. Разумеется, тут возникает масса нюансов, касаемых вопросов
 сокрытия: процесса трояна, файла трояна и трафика трояна. Сокрытие процесса и
 файла трояна выходят за рамки моей темы, а вот про сокрытие трафика я пару
 слов промолвлю.
 
 Hадо ксорить и рорить. Самые простые и лёгкие способы сокрытия данных от
 IDS-систем. рор тридцатидвухбитных слов по константе (или по простой "шумовой"
 функции с коротким периодом), в совокупности с ксором (также с функцией или с
 константой) дадут достаточный уровень зашумлённости передаваемых по HTTP пачек
 данных, чтобы пресечь возможный эвристический анализ со стороны IDS-системы;
 
 Можно сжимать. Простым и лёгким LZH, чуть потяжелее и потруднее ZIP, ещё чуть
 тяжелее, но эффективнее GZIP или совсем экстремально, методом BZIP2.
 
 Можно сделать fetch файлов на компьютер жертвы и download файлов с него, также
 через GET и POST тем же самым HTTP. 
 
 Можно даже реализовать туннелирование данных между локальными портами на
 стороне жертвы и локальными портами на стороне взломщика.
 
 Можно очень многое: ограничением являются только потребности, фантазия
 взломщика и его бюджет.
 
 Вильну опять в сторону: описанный выше метод реализации транспорта -- далеко
 не единственный. Перечислю лишь несколько:
 
 -- можно пытаться пинговать, и пользоваться пингами для транспорта, если они
 не закрыты. попытка пингануть не напрягает фаерволл: пинги происходят не от
 сокетного слоя, и определить отправителя стандартным способом весьма
 затруднительно. так что, если пинги открыты, то отправлять такие сообщения
 можно из любого процесса;
 
 (устал, продолжение будет вечером)
 
 -- транспортом может служить аська (триллиан, миранда) на компьютере жертвы.
 аське номинально разрешена связь с сервером мирабилиса, и этим можно
 воспользоваться для очень удобного транспорта троянской программы (взломщик
 может управлять экземплярами троянов прямо со своего клиента аськи!).
 
 всё просто и незатейливо: создаётся plug-in к аське, который регистрирует
 номер, соединяется с сервером мирабилиса параллельно основному соединению,
 просит авторизации у уина хозяина и сообщает ему "я готов". ну, далее всё
 понятно и очевидно.
 
 а просто всё оттого, что функции для реализации этого транспорта можно брать
 из адресного пространства самой аськи. разыменовывая, например, данные из
 сегмента BSS или отыскивая их GetProcAddr()'ом. да, для этого придётся немного
 раздербанить потроха асечному клиенту и экспериментальным путём научиться
 пользоваться тамошними функциями, зато в результате можно получить очень
 элегантный и лаконичный троян.
 
 короче говоря, можно найти массу вариантов реализации транспорта по первому
 пути, исходя из нацеленности на обход локальных систем защиты.
 
 --- ifmail v.2.15dev5.3
  * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)
 
 

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

 Тема:    Автор:    Дата:  
 о реверсивных троянах -- часть 2   Andrey Sokolov   27 Dec 2004 14:24:00 
Архивное /ru.nethack/16679f60116d0.html, оценка 3 из 5, голосов 10
Яндекс.Метрика
Valid HTML 4.01 Transitional