- 235
- 134
- 30 Май 2016
Искусство зомбирования: азбука создания неугоняемых ботнетов (слито).
Популярность бот-сетей приносит новую волну на черный рынок. Спектр услуг ограничивается лишь фантазией создателя бота: начиная от назойливого спама, который проходит через антиспам-фильтры, как нож сквозь масло, и заканчивая сервисом сбора кредитных карт в промышленных масштабах. Посмотрим на процесс приготовления бота с точки зрения программиста.
Современные бот-сети давно перешли миллионную планку. Их масштабы позволяют своим бот-мастерам «распараллелить» финансовые потоки от предоставляемых услуг. Нынешние подходы к проектированию ботнета позволяет использовать его как для осуществления уже ставших классикой в наше время DDoS-атак, так и для работы на уровне отдельно взятых хостов, например, с целью получения какой-либо конфиденциальной информации, сбора TAN (Transaction authentication number, используется в качестве дополнительного средства аутентификации в сервисах онлайн-банкинга), аккаунтов к целевым ресурсам. И все эти манипуляции осуществляются в параллельном режиме разными частями одной бот-сети.
По мере роста «персональной армии» могут появиться дополнительные подводные камни, которые трудно отследить на этапе проектировки бота и еще труднее от них избавиться, так как любое изменение в его архитектуре может разрушить ботнет, как карточный домик. Именно поэтому у будущего бот-мастера должно быть четкое представление масштабов своей сети, решаемых ею задач и варианты действий на случай ее утраты. Последний пункт особенно актуален для бот-сетей больших масштабов или принадлежащих к кардерской инфраструктуре. Заинтересоваться детищем могут как конкуренты, так и правоохранительные органы. Все возможные риски должны быть также выявлены и устранены на этапе проектировки.
Год назад в нашем журнале концепцию идеального ботнета детально описал Роман Хоменко в своей статье «Вечный ботнет». В ней он изложил принципы создания бота, организацию получения команд от командного центра, а также внес некоторые постулаты проектирования бот-сети. Советую взять его материал за основу. В свою очередь, следуя теоретическим аспектам построения «идеальной армии», мы рассмотрим практическую сторону создания бота.
Архитектура – наше все
Существует множество способов управления зараженными хостами и передача команд каждой машине. Все зависит от конкретных предпочтений бот-мастера. В зависимости от типа используемого протокола командным центром может выступать:
• Веб-сервер - управление осуществляется через веб-интерфейс. В настоящее время самый распространенный способ (кстати, именно его использует нашумевший Zeus).
• Instant Message среда - передача команд по одному из IM-протоколов (ICQ, jabber, MSN и т.п.). Используется в в бот-сетях с небольшим количеством хостов.
• IRC - командный центр находится на одном из IRC-каналов. Морально устаревший метод осуществления контроля. В настоящее время практически не используется из-за высокой степени вероятности изолирования (перехвата) командного центра.
• Twitter-среда - управление ботнетом посредством передачи команд в твиттер-аккаунте. Довольно экзотический способ, но имеет право на существование в условиях повсеместной распространенности социальных сетей и веб-сервисов, предоставляющих свои API. Кстати, в данном случае можно не задумываться о том, что командный центр может упасть из-за нагрузки своей же «армии», ведь большинство данных проектов рассчитаны на огромную аудиторию и имеют соответствующие средства масштабируемости.
• TCP/IP-based – управление посредством протоколов, базирующихся на стеке TCP/IP. Под эту категорию попадают все остальные способы, основанные на передаче команд по экзотическим и самописным протоколам.
Тем не менее обилие данных методов можно классифицировать всего лишь по двум признакам (смотри соответствующие рисунки):
• передача команд посредством командного центра (централизованная топология)
• передача команд от бота к боту или P2P (децентрализованная топология)
Удобство централизованных схем объясняется наличием единого центра, к которому обращаются боты с целью получения задания. Не нужно беспокоиться о своевременном получении команды конкретным ботом. Факты получения, выполнения, успешного/неуспешного завершения задачи легко фиксируются, что позволяет вести детальную статистику. Однако централизованная топология остается актуальна лишь для небольших бот-сетей по следующим причинам:
• плохая масштабируемость (с ростом числа зараженных хостов растет нагрузка на командный центр и увеличивается вероятность осуществления атаки типа «отказ в обслуживании» на сервер, передающий задания);
• централизованное управление (высокая вероятность изолирования командного центра, что немедленно «парализует» весь ботнет).
Децетрализованная топология полностью лишена вышеперечисленных недостатков и, в силу особенностей своей архитектуры, обеспечивает большую «живучесть» бот-сети. Но, как всегда, в бочку меда обязательно кем-то вылета солидная ложка дегтя и, в нашем случае, не одна:
1) Peer-to-peer схема предполагает уведомление каждого бота о существовании других зараженных машин. Эта процедура является довольно «палевной», так как необходимо хранить на каждой зараженной рабочей станции огромный (мы рассматриваем большие ботнеты) файл со списком IP всех ботов сети и в реальном времени его обновлять, если требуется доставка команд каждой «боевой единице».
2) Обновление списка и получение команды требуют дополнительно открытых портов на зараженной машине, что увеличивает вероятность обнаружения ботнета.
3) Значительное время затрачивается на передачу задания от хоста к хосту (P2P) и, соответственно, растет общее время его выполнения.
4) Трудность ведения статистических данных: сколько ботов получили/выполнили задание.
В большинстве случаев обилие недостатков и сложность реализации P2P-ботнетов являются решающим фактором в пользу выбора централизованной топологии. Мы также не будем изобретать велосипед, а воспользуемся опытом мировых практик.
Капризный командный центр, который постоянно находится в условии неустойчивого равновесия, стремясь упасть при малейшем росте нашей «армии», так и норовит отдаться в руки правоохранительных органов, которые вот-вот прикроют главный домен. Пусть прикрывают – мы его сменим.
Псевдослучайные имена
Генератор псевдослучайный чисел имеет одну особенность, которая является ключевой для бот-мастера: получая на вход параметр в виде фиксированного значения, ГПЧ генерирует случайную последовательность, которая будет одинакова на различных рабочих станциях при условии получения их генераторами этого параметра.
Чтобы тебе не пришлось долго искать смысл в использовании ГПЧ, рассмотрим следующую функцию:
Код:
int generator (int seed) {
srand(seed);
//вывод двадцати первых элементов последовательности
for (x = 1; x <= 20; x++)
printf("iteration %d, rand=%d\n", x, rand());
getch();
return 0;
}
Базовыми функциями, отвечающими за инициализацию и генерацию псевдослучайной последовательности, являются давно знакомые нам srand() и rand(). На основе переменной seed функция srand() инициализирует множество чисел, на котором, в свою очередь, будет работать функция генерации rand().
Результат работы функции generator() при значении seed=123:
440
19053
23075
…
Таким образом, seed является тем самым параметром, на основе которого будет генерироваться последовательность доменов.
Легким движением руки и небольшим шевелением извилин генератор псевдослучайной числовой последовательности превращается в генератор псевдослучайной последовательности доменных имен, результат работы которого ты можешь видеть на соответствующем скриншоте.
Способ генерации доменного имени основан на простой работе со строками. Ничего сверхъестественного в исходном коде генератора нет, поэтому приводить его здесь не будем – ищи исходники с комментариями на диске.
Несколько слов можно сказать об окончаниях доменных имен: доменные зоны берутся из массива и склеиваются со сгенерированной строкой, поэтому чем больше массив с этими элементами, тем шире диапазон всевозможных вариантов.
Имея в своем функционале генератор доменного имени, бот, в случае недоступности командного центра на основном домене, генерирует новый и связывается с ним. В свою очередь бот-мастер также имеет в наличии аналогичный генератор (с нужным входным параметром seed), что позволяет ему заранее зарегистрировать новое доменное имя для своей «армии».
Таким образом, мы избавились от одного из основных недостатков централизованной топологии – возможность уничтожения командного центра. Однако остается угроза получения контроля над доменом и несанкционированной передачи команд ботам. Данная проблема решается специально спроектированной админской частью (также известной как «административная панель»).
Ботнет и .NET
Один из методов защиты от несанкционированной передачи заданий ботам заключается в использовании шифрования командного файла на стороне сервера. Клиент, коим выступает зараженная машина, имеет в своем распоряжении ключ для расшифровки этого файла. Идея хорошая, но мы пойдем другим путем, воспользовавшись прелестями современных технологий.
В июньском номере журнала в статье «Уязвимости ONLINE» мы рассмотрели базовые аспекты создания веб-сервисов на основе технологий ASP.NET. Теперь копнем немного глубже и посмотрим, как строятся защищенные веб-приложения – это пригодится нам для построения административной панели командного центра. Веб-приложение, в роли которого выступает «админка», предоставляет ресурсы (то есть командный файл) своим клиентам (ботам). Всем «нежелательным» личностям веб-приложение должно показывать маршрут в сторону леса.
Процесс определения санкционированного клиента состоит из двух последовательных этапов:
• Аутентификация – непосредственно распознавание клиента, запрашивающего ресурс.
• Авторизация – определение, имеет ли аутентифицировавшийся клиент необходимые права на запрашиваемый им ресурс.
Для установки процесса аутентификации в конфигурационном файле веб-сервиса Config.Web необходимо внести соответствующие изменения:
Код:
<configuration>
<security>
<authentication mode="Cookie"/>
</security>
</configuration>
Таким образом мы устанавливаем процесс аутентификации на основе Cookies-файлов. Далее для аутентификации клиента необходимо принять от него данные (UserLogin и UserPassword), сверить их с требуемыми и в случае успеха, передать ему cookies-файлы, которые понадобятся клиенту для получения доступа к защищенной части сайта, где хранится командный файл:
Код:
<script language="C#" runat= server>
void Login_Click(Object sender, EventArgs E) {
if ((UserLogin.Value == "DotSiteTeam")&& (UserPassword.Value == "BestITResource")) {
CookieAuthentication.RedirectFromLoginPage(
UserLogin.Value,true);
}
else { //вывод сообщения о неправильно введенных данных}
}
</script>
В ASP.NET различают два вида авторизации, которые определяют, есть ли у клиента соответствующие права на доступ к запрашиваемому URL, где хранится файл с командами: URL и File. Нам интересен первый способ управления доступом, позволяющий проводить разграничение доступа клиента к ресурсу в зависимости от его имени и роли. Например, следующая конфигурация разрешает доступ к URL всем клиентам, прошедшим аутентификацию и запрещает всем остальным:
Код:
<authorization>
<allow users="*" />
<deny users="?" />
</authorization>
«Пилить» административную часть ботнета можно не менее продолжительное время, чем самого бота, тем более, имея в своем распоряжении интересные технологи защиты веб-приложений ASP.NET, поэтому мы не будем пытаться объять необъятное, а перейдем к ключевой части – боту.
Бот в разрезе
Любой современный ботнет должен подразумевать расширение своего функционала. Зачем? Ну например, если у бот-мастера возникло желание переквалифицировать свою армию зомби в сеть распределенных вычислений, которая будет моделированием последствий ядерных взрывов. Плагинная архитектура позволяет «развязать» руки администратору сети и наращивать или обновлять функционал по мере необходимости. Учитывая данный факт, составим алгоритм действий нашего бота:
1. получение команды от сервера;
2. обработка команды, то есть ее классификация на «известную» или «неизвестную»;
3. обработка соответствующим образом параметров команды в зависимости от ее типа;
4. выполнение команды.
Получение команд заключает в скачивании текстового файла с сервера (command.txt). Реализация скачивания файла берет на себя функция HTTPDownload(char *FileUrl, char *FileName). Данная функция также используется и для скачивания необходимых .dll для ботнета. Я решил не заниматься рутиной, работая с сокетами, а воспользоваться стандартной библиотекой, которая присутствует в Windows: wininet.dll. Данная DLL представляет собой API для доступа к общим протоколам интернет, включая FTP, HTTP и Gopher. Это высокоуровневый API, позволяющий, в отличие от WinSock или TCP/IP, не заботиться о деталях реализации соответствующих интернет протоколов.
Для получения команд, бот должен периодически соединяться с сервером, скачивать командный файл и соответствующим образом его обрабатывать. Под обработкой мы подразумеваем действие, в результате которого бот получает две строки: название команды и строка, содержащая параметры к ней, перечисленные через символ пробела. Командный файл имеет следующую структуру :
<команда(1)> [параметр(1)] [параметр(2)] … [параметр(i)]
<команда(2)> [параметр(1)] [параметр(2)] … [параметр(j)]
…
<команда(k)> [параметр(1)] [параметр(2)] … [параметр
]
где i, j, k меняются в интервале (1; бесконечность).
Действия бота следующие:
1. выделение k-ой строки;
2. передача выделенной строки в функцию, которая реализует подключение библиотеки, необходимой для выполнения команды (функция PlugLibrary());
3. PlugLibrary() соответствующим образом интерпретирует строку и выполняет необходимое действие, зависящие от типа команды.
Парсинг command.txt реализует функция Parse(char *FileName).
В случае необходимости подключения скачанной dll-ки с целью расширения функционала, функция PlugLibrary выполняет следующие инструкции по заранее описанному интерфейсу подключения (он также должен быть оформлен в самой dll):
Код:
//подключение библиотеки
hPlugin = LoadLibrary(DllName);
//определение типа (DefType)
typedef int (*DefType)(char *);
//определение адреса функции "Load", которую экспортирует библиотека
DefType Load = (DefType) GetProcAddress(hPlugin,"Load");
//вызов функции "Load" и передача параметров этой функции
int iCode=(*Load)(Parametrs);
Функция Load, экспортируемая библиотекой, содержит необходимые инструкции, обеспечивающие расширение функционала основной программы-бота.
И это только начало…
В статье мы немного подсмотрели за процессом приготовления ботнета по правильному рецепту. Наше внимание коснулось большинства аспектов искусства зомбирования: проанализированны основные архитектуры бот-сетей, осуществлена реализация наиболее актуальной топологии с устранением присущих ей недостатков, рассмотрена довольно перспективная область использования веб-сервисов в качестве административной панели со своей защищенной зоной, написан плагинный бот, который по мере желания администратора может мутировать до неузнаваемости. И это только начало, ведь сколько еще нюансов осталось за кадром: сокрытие исполняемого файла в системе, разделение ботнета на под сети и т.п. задачи тебе еще предстоит решить. Я лишь задал тебе направление движения, естественно в ознакомительных целях.
Современные бот-сети давно перешли миллионную планку. Их масштабы позволяют своим бот-мастерам «распараллелить» финансовые потоки от предоставляемых услуг. Нынешние подходы к проектированию ботнета позволяет использовать его как для осуществления уже ставших классикой в наше время DDoS-атак, так и для работы на уровне отдельно взятых хостов, например, с целью получения какой-либо конфиденциальной информации, сбора TAN (Transaction authentication number, используется в качестве дополнительного средства аутентификации в сервисах онлайн-банкинга), аккаунтов к целевым ресурсам. И все эти манипуляции осуществляются в параллельном режиме разными частями одной бот-сети.
По мере роста «персональной армии» могут появиться дополнительные подводные камни, которые трудно отследить на этапе проектировки бота и еще труднее от них избавиться, так как любое изменение в его архитектуре может разрушить ботнет, как карточный домик. Именно поэтому у будущего бот-мастера должно быть четкое представление масштабов своей сети, решаемых ею задач и варианты действий на случай ее утраты. Последний пункт особенно актуален для бот-сетей больших масштабов или принадлежащих к кардерской инфраструктуре. Заинтересоваться детищем могут как конкуренты, так и правоохранительные органы. Все возможные риски должны быть также выявлены и устранены на этапе проектировки.
Год назад в нашем журнале концепцию идеального ботнета детально описал Роман Хоменко в своей статье «Вечный ботнет». В ней он изложил принципы создания бота, организацию получения команд от командного центра, а также внес некоторые постулаты проектирования бот-сети. Советую взять его материал за основу. В свою очередь, следуя теоретическим аспектам построения «идеальной армии», мы рассмотрим практическую сторону создания бота.
Архитектура – наше все
Существует множество способов управления зараженными хостами и передача команд каждой машине. Все зависит от конкретных предпочтений бот-мастера. В зависимости от типа используемого протокола командным центром может выступать:
• Веб-сервер - управление осуществляется через веб-интерфейс. В настоящее время самый распространенный способ (кстати, именно его использует нашумевший Zeus).
• Instant Message среда - передача команд по одному из IM-протоколов (ICQ, jabber, MSN и т.п.). Используется в в бот-сетях с небольшим количеством хостов.
• IRC - командный центр находится на одном из IRC-каналов. Морально устаревший метод осуществления контроля. В настоящее время практически не используется из-за высокой степени вероятности изолирования (перехвата) командного центра.
• Twitter-среда - управление ботнетом посредством передачи команд в твиттер-аккаунте. Довольно экзотический способ, но имеет право на существование в условиях повсеместной распространенности социальных сетей и веб-сервисов, предоставляющих свои API. Кстати, в данном случае можно не задумываться о том, что командный центр может упасть из-за нагрузки своей же «армии», ведь большинство данных проектов рассчитаны на огромную аудиторию и имеют соответствующие средства масштабируемости.
• TCP/IP-based – управление посредством протоколов, базирующихся на стеке TCP/IP. Под эту категорию попадают все остальные способы, основанные на передаче команд по экзотическим и самописным протоколам.
Тем не менее обилие данных методов можно классифицировать всего лишь по двум признакам (смотри соответствующие рисунки):
• передача команд посредством командного центра (централизованная топология)
• передача команд от бота к боту или P2P (децентрализованная топология)
Удобство централизованных схем объясняется наличием единого центра, к которому обращаются боты с целью получения задания. Не нужно беспокоиться о своевременном получении команды конкретным ботом. Факты получения, выполнения, успешного/неуспешного завершения задачи легко фиксируются, что позволяет вести детальную статистику. Однако централизованная топология остается актуальна лишь для небольших бот-сетей по следующим причинам:
• плохая масштабируемость (с ростом числа зараженных хостов растет нагрузка на командный центр и увеличивается вероятность осуществления атаки типа «отказ в обслуживании» на сервер, передающий задания);
• централизованное управление (высокая вероятность изолирования командного центра, что немедленно «парализует» весь ботнет).
Децетрализованная топология полностью лишена вышеперечисленных недостатков и, в силу особенностей своей архитектуры, обеспечивает большую «живучесть» бот-сети. Но, как всегда, в бочку меда обязательно кем-то вылета солидная ложка дегтя и, в нашем случае, не одна:
1) Peer-to-peer схема предполагает уведомление каждого бота о существовании других зараженных машин. Эта процедура является довольно «палевной», так как необходимо хранить на каждой зараженной рабочей станции огромный (мы рассматриваем большие ботнеты) файл со списком IP всех ботов сети и в реальном времени его обновлять, если требуется доставка команд каждой «боевой единице».
2) Обновление списка и получение команды требуют дополнительно открытых портов на зараженной машине, что увеличивает вероятность обнаружения ботнета.
3) Значительное время затрачивается на передачу задания от хоста к хосту (P2P) и, соответственно, растет общее время его выполнения.
4) Трудность ведения статистических данных: сколько ботов получили/выполнили задание.
В большинстве случаев обилие недостатков и сложность реализации P2P-ботнетов являются решающим фактором в пользу выбора централизованной топологии. Мы также не будем изобретать велосипед, а воспользуемся опытом мировых практик.
Капризный командный центр, который постоянно находится в условии неустойчивого равновесия, стремясь упасть при малейшем росте нашей «армии», так и норовит отдаться в руки правоохранительных органов, которые вот-вот прикроют главный домен. Пусть прикрывают – мы его сменим.
Псевдослучайные имена
Генератор псевдослучайный чисел имеет одну особенность, которая является ключевой для бот-мастера: получая на вход параметр в виде фиксированного значения, ГПЧ генерирует случайную последовательность, которая будет одинакова на различных рабочих станциях при условии получения их генераторами этого параметра.
Чтобы тебе не пришлось долго искать смысл в использовании ГПЧ, рассмотрим следующую функцию:
Код:
int generator (int seed) {
srand(seed);
//вывод двадцати первых элементов последовательности
for (x = 1; x <= 20; x++)
printf("iteration %d, rand=%d\n", x, rand());
getch();
return 0;
}
Базовыми функциями, отвечающими за инициализацию и генерацию псевдослучайной последовательности, являются давно знакомые нам srand() и rand(). На основе переменной seed функция srand() инициализирует множество чисел, на котором, в свою очередь, будет работать функция генерации rand().
Результат работы функции generator() при значении seed=123:
440
19053
23075
…
Таким образом, seed является тем самым параметром, на основе которого будет генерироваться последовательность доменов.
Легким движением руки и небольшим шевелением извилин генератор псевдослучайной числовой последовательности превращается в генератор псевдослучайной последовательности доменных имен, результат работы которого ты можешь видеть на соответствующем скриншоте.
Способ генерации доменного имени основан на простой работе со строками. Ничего сверхъестественного в исходном коде генератора нет, поэтому приводить его здесь не будем – ищи исходники с комментариями на диске.
Несколько слов можно сказать об окончаниях доменных имен: доменные зоны берутся из массива и склеиваются со сгенерированной строкой, поэтому чем больше массив с этими элементами, тем шире диапазон всевозможных вариантов.
Имея в своем функционале генератор доменного имени, бот, в случае недоступности командного центра на основном домене, генерирует новый и связывается с ним. В свою очередь бот-мастер также имеет в наличии аналогичный генератор (с нужным входным параметром seed), что позволяет ему заранее зарегистрировать новое доменное имя для своей «армии».
Таким образом, мы избавились от одного из основных недостатков централизованной топологии – возможность уничтожения командного центра. Однако остается угроза получения контроля над доменом и несанкционированной передачи команд ботам. Данная проблема решается специально спроектированной админской частью (также известной как «административная панель»).
Ботнет и .NET
Один из методов защиты от несанкционированной передачи заданий ботам заключается в использовании шифрования командного файла на стороне сервера. Клиент, коим выступает зараженная машина, имеет в своем распоряжении ключ для расшифровки этого файла. Идея хорошая, но мы пойдем другим путем, воспользовавшись прелестями современных технологий.
В июньском номере журнала в статье «Уязвимости ONLINE» мы рассмотрели базовые аспекты создания веб-сервисов на основе технологий ASP.NET. Теперь копнем немного глубже и посмотрим, как строятся защищенные веб-приложения – это пригодится нам для построения административной панели командного центра. Веб-приложение, в роли которого выступает «админка», предоставляет ресурсы (то есть командный файл) своим клиентам (ботам). Всем «нежелательным» личностям веб-приложение должно показывать маршрут в сторону леса.
Процесс определения санкционированного клиента состоит из двух последовательных этапов:
• Аутентификация – непосредственно распознавание клиента, запрашивающего ресурс.
• Авторизация – определение, имеет ли аутентифицировавшийся клиент необходимые права на запрашиваемый им ресурс.
Для установки процесса аутентификации в конфигурационном файле веб-сервиса Config.Web необходимо внести соответствующие изменения:
Код:
<configuration>
<security>
<authentication mode="Cookie"/>
</security>
</configuration>
Таким образом мы устанавливаем процесс аутентификации на основе Cookies-файлов. Далее для аутентификации клиента необходимо принять от него данные (UserLogin и UserPassword), сверить их с требуемыми и в случае успеха, передать ему cookies-файлы, которые понадобятся клиенту для получения доступа к защищенной части сайта, где хранится командный файл:
Код:
<script language="C#" runat= server>
void Login_Click(Object sender, EventArgs E) {
if ((UserLogin.Value == "DotSiteTeam")&& (UserPassword.Value == "BestITResource")) {
CookieAuthentication.RedirectFromLoginPage(
UserLogin.Value,true);
}
else { //вывод сообщения о неправильно введенных данных}
}
</script>
В ASP.NET различают два вида авторизации, которые определяют, есть ли у клиента соответствующие права на доступ к запрашиваемому URL, где хранится файл с командами: URL и File. Нам интересен первый способ управления доступом, позволяющий проводить разграничение доступа клиента к ресурсу в зависимости от его имени и роли. Например, следующая конфигурация разрешает доступ к URL всем клиентам, прошедшим аутентификацию и запрещает всем остальным:
Код:
<authorization>
<allow users="*" />
<deny users="?" />
</authorization>
«Пилить» административную часть ботнета можно не менее продолжительное время, чем самого бота, тем более, имея в своем распоряжении интересные технологи защиты веб-приложений ASP.NET, поэтому мы не будем пытаться объять необъятное, а перейдем к ключевой части – боту.
Бот в разрезе
Любой современный ботнет должен подразумевать расширение своего функционала. Зачем? Ну например, если у бот-мастера возникло желание переквалифицировать свою армию зомби в сеть распределенных вычислений, которая будет моделированием последствий ядерных взрывов. Плагинная архитектура позволяет «развязать» руки администратору сети и наращивать или обновлять функционал по мере необходимости. Учитывая данный факт, составим алгоритм действий нашего бота:
1. получение команды от сервера;
2. обработка команды, то есть ее классификация на «известную» или «неизвестную»;
3. обработка соответствующим образом параметров команды в зависимости от ее типа;
4. выполнение команды.
Получение команд заключает в скачивании текстового файла с сервера (command.txt). Реализация скачивания файла берет на себя функция HTTPDownload(char *FileUrl, char *FileName). Данная функция также используется и для скачивания необходимых .dll для ботнета. Я решил не заниматься рутиной, работая с сокетами, а воспользоваться стандартной библиотекой, которая присутствует в Windows: wininet.dll. Данная DLL представляет собой API для доступа к общим протоколам интернет, включая FTP, HTTP и Gopher. Это высокоуровневый API, позволяющий, в отличие от WinSock или TCP/IP, не заботиться о деталях реализации соответствующих интернет протоколов.
Для получения команд, бот должен периодически соединяться с сервером, скачивать командный файл и соответствующим образом его обрабатывать. Под обработкой мы подразумеваем действие, в результате которого бот получает две строки: название команды и строка, содержащая параметры к ней, перечисленные через символ пробела. Командный файл имеет следующую структуру :
<команда(1)> [параметр(1)] [параметр(2)] … [параметр(i)]
<команда(2)> [параметр(1)] [параметр(2)] … [параметр(j)]
…
<команда(k)> [параметр(1)] [параметр(2)] … [параметр
]где i, j, k меняются в интервале (1; бесконечность).
Действия бота следующие:
1. выделение k-ой строки;
2. передача выделенной строки в функцию, которая реализует подключение библиотеки, необходимой для выполнения команды (функция PlugLibrary());
3. PlugLibrary() соответствующим образом интерпретирует строку и выполняет необходимое действие, зависящие от типа команды.
Парсинг command.txt реализует функция Parse(char *FileName).
В случае необходимости подключения скачанной dll-ки с целью расширения функционала, функция PlugLibrary выполняет следующие инструкции по заранее описанному интерфейсу подключения (он также должен быть оформлен в самой dll):
Код:
//подключение библиотеки
hPlugin = LoadLibrary(DllName);
//определение типа (DefType)
typedef int (*DefType)(char *);
//определение адреса функции "Load", которую экспортирует библиотека
DefType Load = (DefType) GetProcAddress(hPlugin,"Load");
//вызов функции "Load" и передача параметров этой функции
int iCode=(*Load)(Parametrs);
Функция Load, экспортируемая библиотекой, содержит необходимые инструкции, обеспечивающие расширение функционала основной программы-бота.
И это только начало…
В статье мы немного подсмотрели за процессом приготовления ботнета по правильному рецепту. Наше внимание коснулось большинства аспектов искусства зомбирования: проанализированны основные архитектуры бот-сетей, осуществлена реализация наиболее актуальной топологии с устранением присущих ей недостатков, рассмотрена довольно перспективная область использования веб-сервисов в качестве административной панели со своей защищенной зоной, написан плагинный бот, который по мере желания администратора может мутировать до неузнаваемости. И это только начало, ведь сколько еще нюансов осталось за кадром: сокрытие исполняемого файла в системе, разделение ботнета на под сети и т.п. задачи тебе еще предстоит решить. Я лишь задал тебе направление движения, естественно в ознакомительных целях.