Опыт грязного ремесла.
Почему я назвал именно так? Потому что я никогда не считал тем что делаю правильным или нужным во благо людям, я прекрасно осознаю что это делается для корыстных целей для обмана/кражи и т.п. и всё это ради денег, которые в итоге всех их губят, поэтому всё справедливо каждый получает своё...
Меня в этой сфере интересовало лишь одно - люди, я всегда старался понять их ход мышления, я не учился программированию, я учился мыслить по другому, только так я научился видеть то чего не видел раньше в том чего уже знал.
Я не претендую на правильность своих мыслей это всего лишь эксперименты из моего опыта, которые приносили определённые результаты в течение разного времени, отмечу что тут все мои мысли вперемешку без хронологии, к чему-то я пришёл уже очень давно, а что-то решил недавно.
Тут не будет готово кода или чего-то подобного, кто достоит понять, тот и так всё поймёт.
Часть 1. Связки.
Давным давно ещё когда мне приходилось делать связки я конечно же был далеко не первым и не делал сплойты. Всё было точно так же как и сейчас брали паблик сплойт, потом уже покупали через 10ые лицы приватные от реверсеров и вязали связки.
Смотря сейчас и сравнивая с тем что бы пару лет назад хочу сказать ничего не поменялось всё на том же уровне, очень странно но это так, хотя не без исключений.
Я поделюсь своим опытом из своих экспериментов при связкописании.
1. Первое что хочу отметить связка это не всего лишь админка которая показывает красивые статы, в первую очередь это интеллектуальная система которая анализирует трафик для того что бы подобрать подходящий сплойт на выдачу. Поэтому меня до сих пор удивляют связки по 600-1к+ в которых весь вывод идёт сплошным js кодом сплойтов один за другим, кто-то ставит таймеры, кто-то ставит переменные и ловит их выполнение...
Так вот я всегда руководствовался тем что прежде чем что-то делать нужно это придумать, даже если оно уже придумано. Ведь все мы люди и все мы разные, а значит и мыслим по разному. Мои изучения были наложены на сбор статистики, что бы понять как правильно нужно выдавать сплойты нужно было понять для чего их приходится выдавать. Были созданы мной совместно с моим партнёром 47 скрипты.
Статистику собирали следующую:
- ОС их версии
- Браузеры и их версии
- Плагины в браузерах и их версии (до сих пор нигде не встречал этого ну кроме последних где pdf и flash определяется, а ведь странно потому что сплойты 90% это баги в плагинах)
Сейчас думаю это не будет секретом очень много генеренного трафика, добавив проверку на работу js и простую проверку с куками и редиректом можно его отсеить и увидеть кстати внушительные цифры если собрать в отдельную стату он будет не меньше 10% что уменьшают пробив пустой выдачей сплойтов, а это уже недоработка связки.
Так вот анализ трафика с разных источников по этим данным показал довольно ясную картину на сколько этот трафик вообще пробиваемый. Но что самое главное в чём была суть определить % наличия уязвимых плагинов под которые есть сплойты.
Даже после такого анализа можно только примерно составить процент пробива на данном трафике.
И так идём дальше ближе к кодерской сути.
Для правильной выдачи сплойтов мы использовли определение js и проверку кук, ОС, Браузера, учитывая версии, определять наличие уязвимого плагина в браузере и только после этого собирать выдачу из подходящих вариантов или делать бэк редирект.
Что касается о самой выдачи сплойтов о чём я писал выше, вариант со сплошной выдачей, таймерами и переменными в моих экспериментах показали себя хуже чем мой вариант с ифреймами.
Небольшая ремарка: 47 в новых тестах сказал что моя версия работает похуже и сделал новую свою выдачу, поэтому решать на сколько это хорошо вам.
Что же это за ифреймы, постараюсь объяснить с начало теорию почему я к ним пришёл.
И так моя логика пошла от работы самого сплойта, т.е. это выполнения шеллкода в выделенном участке памяти другого процесса. И тут я подумал а что же бывает когда мы выполняем по 3-4 сплойта в одном и том же процессе но используем разные уязвимости только получается эффективность должна снижаться и вообще могут быть непредсказуемые последствия типа overflow т.к. сплойты не предназначены для параллельной работы.
А что из себя представляют ифреймы - это как я думаю всё же дочерние процессы или отдельные как в некоторых браузерах табы, которые независимые друг от друга их объединяет только процесс-родитель, а значит мы получаем место полигона для каждого сплойта. Таким образом после проведения анализа я сделал выдачу в ифреймах каждый сплойт подгружался в отдельном. Работать они стали значительно быстрее и эффективность пробива увеличилась.
В заключение хочу сказать про крипторы выдачи. Криптор должен не только уметь разбавлять код или обфусцировать но и иметь пакер, чем больше размер сплойта тем меньше вероятность его выполнения, всё таки он стоит не на самом сайте а грузиться через ифрейм который является внутренней страницей сайта и может быть выгружен или произойти редирект и сплойт не успеет отработать, а его время выполнения зачастую зависит от параметров железа юзера т.к. js выполняется на стороне клиента а не сервера. Так же криптор не должен иметь кучи циклов которые могут привести к ошибкам браузера, например ФФ все его функции так или иначе связаны с js всякие настройки модули и порой даже в обычном коде они вызывают ошибки пока не перезапустишь браузер, поэтому стоит это обязательно учитывать.
Думаю на этом можно подвести итог.
Часть 2. Админки для троянов.
Многие кто пишут админки зачастую начинающие кодеры или вообще не вебкодеры а прикладные пытающиеся написать самому админку что бы никому не надо было платить или с кем-то делиться.
Из своих наблюдей и опыта могу лишь поделиться некоторыми особенностями в этом деле, т.к. что бы написать админку для серьёзного ботнета мало знать просто php и mysql их нужно отлично знать, а главное нужно понимать весь принцип работы что бы делать заплатки на все узкие места которых в таких проектах очень много.
Про сами админки думаю рассказывать нечего делайте юзабильно удобно и функционально, это дело каждого как она будет выглядеть и какой функционал вести.
Я хочу уделить внимание части где идёт работа с самим ботом, а так же немного об проектировании архитектуры БД.
Прежде чем начать что-то писать лично я беру листок бумаги и карандаш и начинаю рисовать, т.к. стереть резинкой и перерисовать гораздо быстрее чем при тестировании переписать код
Но рисовать конечно надо не окошки где что будет, а рисовать структуру базы данных.
Нужно определиться с функционалом бота что бы правильно и оптимизировано сделать общения с ним, ведь их будет тысячи.
Я отмечу несколько пунктов которые помогают при больших нагрузках:
1. Таблицы не должны иметь много полей (как делают например в зевсе по 15-20
2. Если предполагается большое кол-во строковых параметров типов varchar и text то лучше вынести их в отдельные таблицы и сделать связующим id.
Теперь объясню почему нужны эти 2 пункта. MySQL имеет свои лимиты а именно позволяет в одной таблицы хранить до 4Гб данных, на сколько помню это связано с файловой системой ОС. Так вот если вы рассчитываете что ваш ботнет будет иметь 100к ботов тогда сразу нужно посчитать какие данные вы о ботах будете хранить и учесть эти данные в байтах после чего умножить на 100к и выяснить поместиться ли это, забегу на перёд учитывайте так же поиск по этим данных например если бот уже есть в БД или выборку по стране или типу к примеру, ведь SELECT это не INSERT он резервирует память при поиске в таблице и чем больше там данных тем больше потребует памяти что бы в них поискать.
3. Если данные в таблицах о боте будут обновлятся при каждом его отстуке, то эти данные должны быть связаны 1 параметром бота либо его id который будет auto_increment в главной таблице, либо его id который будет передавать сам бот, это нужно что бы можно было сделать выборку этих данных в 1 запрос с помощью LEFT JOIN а не пришлось делать по не скольку запросов.
4. Таблицы для логов нужно создавать в зависимости от их назначения и дальнейшего использования. Т.е. например если это соксы то можно хранить всё в 1 таблице так будет удобнее с ними работать а главное менее затратно по ресурсам. Если это логи трояна, то лучше делать разбивку на даты используя вложенные таблицы формата 2009_12__20, 2009_12__21, а так же придерживаясь правилам 1 и 2 для этих таблиц.
Думаю эти основные момент с которыми я сталкивался при проектирование.
Дальше перейдём к гейту - скрипту работающим с ботом.
В нём я хочу отметить следующие правила:
1. Использовать нужно минимальное кол-во обращений к БД, не стоит делать лишних.
2. Не нужно делать поисков и выборок по большим таблицам или спискам таблиц, не в коем случаи нельзя использовать LIKE %%.
3. INSERT лучше использовать с DELAY
По этим 3-м пунктом причина одна, нужно максимально сократить время на выполнения всех запросов и отдачи ответа боту, т.к. он держит соединение с сервером забивает канал, а так же при долгих запросах если они будут частые будут сбои в работе БД. Самый оптимальный вариант это в 3 запроса(он может быть больше и не портить картины):
1) Определили новый бот или нет
2) Получили список команд
3) Обновили данные о боте или добавили нового
Всё. Остальное уже нужно оптимизировать в минимальное кол-во запросов и с минимальными затратами на память и время.
4. При выдачи команд лучше их шифровать, я всегда использую между обменом данных с ботом рандомный ключ внутри самих команд определяющий по кол-ву символов или чему-то другому.
5. Если нужно передавать боту файлы на сервер лучшей вариант будет передача через PUT а приём через php://input так надёжнее и быстрее.
6. Так же лучше всего использовать mod_rewrite и id заданий или файлов для их отдачи по отдельным url, если в этом есть необходимость.
7. Для защиты лучше использовать header параметр который вшит в бота, в нём передавать ключевую фразу которую проверять в запросах, так же можно использовать алгоритм который будет динамически генерировать эту фразу от каких-то особых постоянно меняющихся параметров что бы для каждого запроса она была уникальный, например: от времени и урл md5 хеш. Так же можно генерировать от времени и ид бота временные урл по которым бот может взять только 1 раз задание или файл.
Ну думаю на этом советов хватит, главное что админка должна проектироваться вместе с ботом а не отдельно, только тогда можно будет достичь максимально эффекта взаимодействия, например учитывать интервал отстука бота и интервал отправки логов тем самым разгружая от большого кол-во запросов на сервер. А так же использование шифрования и других средств защиты обмена данных.
20.12.2009 (с) Одинокий Волк aka Lonely Wolf
UPD. Добавлена перелинковка со статьёй на других форумах, т.к. везде разные комментарии и некоторые интересные вопросы и ответы на них.
https://forum.web-hack.ru/index.php?showtopic=91869
http://exploit.in/forum/index.php?showtopic=31258
Почему я назвал именно так? Потому что я никогда не считал тем что делаю правильным или нужным во благо людям, я прекрасно осознаю что это делается для корыстных целей для обмана/кражи и т.п. и всё это ради денег, которые в итоге всех их губят, поэтому всё справедливо каждый получает своё...
Меня в этой сфере интересовало лишь одно - люди, я всегда старался понять их ход мышления, я не учился программированию, я учился мыслить по другому, только так я научился видеть то чего не видел раньше в том чего уже знал.
Я не претендую на правильность своих мыслей это всего лишь эксперименты из моего опыта, которые приносили определённые результаты в течение разного времени, отмечу что тут все мои мысли вперемешку без хронологии, к чему-то я пришёл уже очень давно, а что-то решил недавно.
Тут не будет готово кода или чего-то подобного, кто достоит понять, тот и так всё поймёт.
Часть 1. Связки.
Давным давно ещё когда мне приходилось делать связки я конечно же был далеко не первым и не делал сплойты. Всё было точно так же как и сейчас брали паблик сплойт, потом уже покупали через 10ые лицы приватные от реверсеров и вязали связки.
Смотря сейчас и сравнивая с тем что бы пару лет назад хочу сказать ничего не поменялось всё на том же уровне, очень странно но это так, хотя не без исключений.
Я поделюсь своим опытом из своих экспериментов при связкописании.
1. Первое что хочу отметить связка это не всего лишь админка которая показывает красивые статы, в первую очередь это интеллектуальная система которая анализирует трафик для того что бы подобрать подходящий сплойт на выдачу. Поэтому меня до сих пор удивляют связки по 600-1к+ в которых весь вывод идёт сплошным js кодом сплойтов один за другим, кто-то ставит таймеры, кто-то ставит переменные и ловит их выполнение...
Так вот я всегда руководствовался тем что прежде чем что-то делать нужно это придумать, даже если оно уже придумано. Ведь все мы люди и все мы разные, а значит и мыслим по разному. Мои изучения были наложены на сбор статистики, что бы понять как правильно нужно выдавать сплойты нужно было понять для чего их приходится выдавать. Были созданы мной совместно с моим партнёром 47 скрипты.
Статистику собирали следующую:
- ОС их версии
- Браузеры и их версии
- Плагины в браузерах и их версии (до сих пор нигде не встречал этого ну кроме последних где pdf и flash определяется, а ведь странно потому что сплойты 90% это баги в плагинах)
Сейчас думаю это не будет секретом очень много генеренного трафика, добавив проверку на работу js и простую проверку с куками и редиректом можно его отсеить и увидеть кстати внушительные цифры если собрать в отдельную стату он будет не меньше 10% что уменьшают пробив пустой выдачей сплойтов, а это уже недоработка связки.
Так вот анализ трафика с разных источников по этим данным показал довольно ясную картину на сколько этот трафик вообще пробиваемый. Но что самое главное в чём была суть определить % наличия уязвимых плагинов под которые есть сплойты.
Даже после такого анализа можно только примерно составить процент пробива на данном трафике.
И так идём дальше ближе к кодерской сути.
Для правильной выдачи сплойтов мы использовли определение js и проверку кук, ОС, Браузера, учитывая версии, определять наличие уязвимого плагина в браузере и только после этого собирать выдачу из подходящих вариантов или делать бэк редирект.
Что касается о самой выдачи сплойтов о чём я писал выше, вариант со сплошной выдачей, таймерами и переменными в моих экспериментах показали себя хуже чем мой вариант с ифреймами.
Небольшая ремарка: 47 в новых тестах сказал что моя версия работает похуже и сделал новую свою выдачу, поэтому решать на сколько это хорошо вам.
Что же это за ифреймы, постараюсь объяснить с начало теорию почему я к ним пришёл.
И так моя логика пошла от работы самого сплойта, т.е. это выполнения шеллкода в выделенном участке памяти другого процесса. И тут я подумал а что же бывает когда мы выполняем по 3-4 сплойта в одном и том же процессе но используем разные уязвимости только получается эффективность должна снижаться и вообще могут быть непредсказуемые последствия типа overflow т.к. сплойты не предназначены для параллельной работы.
А что из себя представляют ифреймы - это как я думаю всё же дочерние процессы или отдельные как в некоторых браузерах табы, которые независимые друг от друга их объединяет только процесс-родитель, а значит мы получаем место полигона для каждого сплойта. Таким образом после проведения анализа я сделал выдачу в ифреймах каждый сплойт подгружался в отдельном. Работать они стали значительно быстрее и эффективность пробива увеличилась.
В заключение хочу сказать про крипторы выдачи. Криптор должен не только уметь разбавлять код или обфусцировать но и иметь пакер, чем больше размер сплойта тем меньше вероятность его выполнения, всё таки он стоит не на самом сайте а грузиться через ифрейм который является внутренней страницей сайта и может быть выгружен или произойти редирект и сплойт не успеет отработать, а его время выполнения зачастую зависит от параметров железа юзера т.к. js выполняется на стороне клиента а не сервера. Так же криптор не должен иметь кучи циклов которые могут привести к ошибкам браузера, например ФФ все его функции так или иначе связаны с js всякие настройки модули и порой даже в обычном коде они вызывают ошибки пока не перезапустишь браузер, поэтому стоит это обязательно учитывать.
Думаю на этом можно подвести итог.
Часть 2. Админки для троянов.
Многие кто пишут админки зачастую начинающие кодеры или вообще не вебкодеры а прикладные пытающиеся написать самому админку что бы никому не надо было платить или с кем-то делиться.
Из своих наблюдей и опыта могу лишь поделиться некоторыми особенностями в этом деле, т.к. что бы написать админку для серьёзного ботнета мало знать просто php и mysql их нужно отлично знать, а главное нужно понимать весь принцип работы что бы делать заплатки на все узкие места которых в таких проектах очень много.
Про сами админки думаю рассказывать нечего делайте юзабильно удобно и функционально, это дело каждого как она будет выглядеть и какой функционал вести.
Я хочу уделить внимание части где идёт работа с самим ботом, а так же немного об проектировании архитектуры БД.
Прежде чем начать что-то писать лично я беру листок бумаги и карандаш и начинаю рисовать, т.к. стереть резинкой и перерисовать гораздо быстрее чем при тестировании переписать код
Но рисовать конечно надо не окошки где что будет, а рисовать структуру базы данных.
Нужно определиться с функционалом бота что бы правильно и оптимизировано сделать общения с ним, ведь их будет тысячи.
Я отмечу несколько пунктов которые помогают при больших нагрузках:
1. Таблицы не должны иметь много полей (как делают например в зевсе по 15-20
2. Если предполагается большое кол-во строковых параметров типов varchar и text то лучше вынести их в отдельные таблицы и сделать связующим id.
Теперь объясню почему нужны эти 2 пункта. MySQL имеет свои лимиты а именно позволяет в одной таблицы хранить до 4Гб данных, на сколько помню это связано с файловой системой ОС. Так вот если вы рассчитываете что ваш ботнет будет иметь 100к ботов тогда сразу нужно посчитать какие данные вы о ботах будете хранить и учесть эти данные в байтах после чего умножить на 100к и выяснить поместиться ли это, забегу на перёд учитывайте так же поиск по этим данных например если бот уже есть в БД или выборку по стране или типу к примеру, ведь SELECT это не INSERT он резервирует память при поиске в таблице и чем больше там данных тем больше потребует памяти что бы в них поискать.
3. Если данные в таблицах о боте будут обновлятся при каждом его отстуке, то эти данные должны быть связаны 1 параметром бота либо его id который будет auto_increment в главной таблице, либо его id который будет передавать сам бот, это нужно что бы можно было сделать выборку этих данных в 1 запрос с помощью LEFT JOIN а не пришлось делать по не скольку запросов.
4. Таблицы для логов нужно создавать в зависимости от их назначения и дальнейшего использования. Т.е. например если это соксы то можно хранить всё в 1 таблице так будет удобнее с ними работать а главное менее затратно по ресурсам. Если это логи трояна, то лучше делать разбивку на даты используя вложенные таблицы формата 2009_12__20, 2009_12__21, а так же придерживаясь правилам 1 и 2 для этих таблиц.
Думаю эти основные момент с которыми я сталкивался при проектирование.
Дальше перейдём к гейту - скрипту работающим с ботом.
В нём я хочу отметить следующие правила:
1. Использовать нужно минимальное кол-во обращений к БД, не стоит делать лишних.
2. Не нужно делать поисков и выборок по большим таблицам или спискам таблиц, не в коем случаи нельзя использовать LIKE %%.
3. INSERT лучше использовать с DELAY
По этим 3-м пунктом причина одна, нужно максимально сократить время на выполнения всех запросов и отдачи ответа боту, т.к. он держит соединение с сервером забивает канал, а так же при долгих запросах если они будут частые будут сбои в работе БД. Самый оптимальный вариант это в 3 запроса(он может быть больше и не портить картины):
1) Определили новый бот или нет
2) Получили список команд
3) Обновили данные о боте или добавили нового
Всё. Остальное уже нужно оптимизировать в минимальное кол-во запросов и с минимальными затратами на память и время.
4. При выдачи команд лучше их шифровать, я всегда использую между обменом данных с ботом рандомный ключ внутри самих команд определяющий по кол-ву символов или чему-то другому.
5. Если нужно передавать боту файлы на сервер лучшей вариант будет передача через PUT а приём через php://input так надёжнее и быстрее.
6. Так же лучше всего использовать mod_rewrite и id заданий или файлов для их отдачи по отдельным url, если в этом есть необходимость.
7. Для защиты лучше использовать header параметр который вшит в бота, в нём передавать ключевую фразу которую проверять в запросах, так же можно использовать алгоритм который будет динамически генерировать эту фразу от каких-то особых постоянно меняющихся параметров что бы для каждого запроса она была уникальный, например: от времени и урл md5 хеш. Так же можно генерировать от времени и ид бота временные урл по которым бот может взять только 1 раз задание или файл.
Ну думаю на этом советов хватит, главное что админка должна проектироваться вместе с ботом а не отдельно, только тогда можно будет достичь максимально эффекта взаимодействия, например учитывать интервал отстука бота и интервал отправки логов тем самым разгружая от большого кол-во запросов на сервер. А так же использование шифрования и других средств защиты обмена данных.
20.12.2009 (с) Одинокий Волк aka Lonely Wolf
UPD. Добавлена перелинковка со статьёй на других форумах, т.к. везде разные комментарии и некоторые интересные вопросы и ответы на них.
https://forum.web-hack.ru/index.php?showtopic=91869
http://exploit.in/forum/index.php?showtopic=31258
