Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #128, АВГУСТ 2009 г.

Вечный ботнет. Принципы защиты больших бот-сетей

Роман «predidentua» Хоменко (http://tutamc.com, spirt40@gmail.com)

Большие ботнеты - закрытая тема, на которую не то что в паблике не разговаривают, а даже в сверх-секретном-привате мало интересных обсуждений. И одна из причин – ограниченное количество таких бот-сетей (ведь мы говорим о сотнях тысяч зараженных компов!). Но, несмотря на относительную закрытость этой информации, я тебе поведаю абсолютно все самое интересное.

Два года назад моя «аналитическая» группа получила заказ на разработку идеальной архитектуры большого ботнета. Месяц ушел на изучение существующих решений и продумывание своих вариантов. То, что получилось, было реализовано и сейчас отлично работает :). С заказчиком был договор, что 2 года мы не будем распространять эту информацию. Сейчас время вышло, и ты будешь первый, кто, может быть, сумеет реализовать архитектуру для своего ботнета.
В статье мы рассмотрим:

  • Условия существования больших ботнетов
  • Удержание контроля
  • Генерацию доменов
  • Масштабируемость
  • Возможность разделения
  • Подачу команд, их защиту
  • Возврат результатов

Ох, непростая жизнь у больших ботнетов...

Если у тебя ботнет на 1000 или 10.000 компов, то, разумеется, с ним много проблем. Но все они кажутся ничтожными по сравнению с траблами, когда размер сети перевалил за цифру в 100.000. На тебя и твой ботнет откроют настоящую охоту антивирусные компании, правоохранительные органы и обычные гении, которым от нефиг делать захочется посмотреть кишки твоего бота. Да и «коллеги» не оставят в покое, – всеми средствами будут пытаться угнать ботнет. Тебя, конечно, ждет слава, и может даже покажут по ТВ, но этот пиар способен полностью убить весь бизнес, если архитектура ботнета окажется плохой.

Это война, и в ней можно победить, лишь использовав последние достижение в науке. Чтобы убить твой ботнет, «враги» будут анализировать его, смотреть, что и как он делает, да и еще дизассемблировать код. И никакие антиотладочные приемы, многократная полиморфная криптовка и прочее не помогут закрыть от них внутренности бота.

С этой проблемой можно бороться, соблюдая первое правило ботнетов: «Нужно строить ботов, считая, что вся информация о них будет полностью открыта».

Вторая проблема возникает с масштабом ботнета. Огромное количество ботов не выдержит ни один сервак, а поставить кластер с распределителями нагрузки у тебя не получится, потому что это слишком сложно и долго. Да и даже если все будет готово, – придут федералы (я так буду называть ФБР, ФСБ, СБУ и пр.) и быстренько все конфискуют. С этого рождается второе правило: «Ботнет должен управляться с обычных серверов».
Приступим к рассмотрению архитектуры, соответствующей этим правилам.

Командный центр

Способ общения с ботами - это «позвоночник» ботнета. Раньше очень популярной была передача команд через IRC, где боты заходили в заранее определенные комнаты и ждали, что кто-то передаст им команду. Ну, этот метод только археологи сейчас используют, и о множествах его проблем даже не хочется говорить. Сейчас чаще всего юзается схема p2p или web.

p2p - достаточно интересная схема, которая имеет право на жизнь при больших ботнетах. В ней преимуществом служит то, что нагрузка по передаче команд лежит на самих ботах. Минусов в ней тоже хватает:

  • Сложность архитектуры
  • Нестабильность сети
  • «Палевность» открытия портов
  • Сложность контроля
  • Сложность отдачи результатов от ботов
  • И многое прочее...

Управление ботнетом по web'у – пока самый идеальный вариант. К примеру, возьмем Zeus. У него в конфиге прописываем основной домен, где админка и дополнительный домен (если первый сервак накроется). Но если завтра ботов будет много, они легко положат сервак, а если сервак и выдержит, то послезавтра придут федералы и прикроют как основной, так и дополнительный домен, после чего уже восстановить управление не удастся. Эта схема абсолютно не подходит для больших ботнетов.

Генератор доменов

Как в известном фильме легким движением руки штаны превращаются в шорты, так и мы можем бесполезную схему превратить в идеальную. И ключевая идея – в динамической генерации доменов, через которые бот будет общаться. Генерировать домены будем, используя генератор псевдослучайных чисел (ГПСЧ). Если ты не знаком с ним, посмотри врезку – там я все коротко описал. Для нас важна одна фишка: если на вход генератора дать число 1234, генератор может вернуть: 6452, 12, 761 и т.д. И сколько бы раз и на каком компьютере это ни повторяли, всегда последовательность будет одинакова.

Исходя из этого, мы можем написать функцию, что будет использовать генератор псевдослучайных чисел, и если передать какое-то число на генератор, он сможет сгенерировать случайную бесконечную последовательность доменов. Нам лишь нужно для синхронизации всем ботам передать одинаковое начальное число. С учетом всех замечаний принцип работы будет следующим:

  • Генерируем псевдослучайный домен
  • Проверяем, есть ли на главной странице домена какой-то определенный текст - маркер
  • Если маркера нет, – возвращаемся к первому пункту
  • Если маркер есть, то получаем команду для исполнения

Окончания же доменов не генерируется полностью случайно, а выбираются из массива, который может содержать как обычные окончания, так и окончания бесплатных хостингов. Чем список будет больше - тем лучше. Он может выглядеть так:

.com
.org
.ho.ua

Где «.ho.ua» - обычный бесплатный хостинг. Если он попадет в последовательность, то нам даже не нужно будет покупать домен, а просто бесплатно себе зарегаем поддомен. Этого будет достаточно.

Бот, после проверки маркера, должен запрашивать определенный текстовый файлик, к примеру, temp123.txt, и оттуда брать команду для исполнения.
Говоря о задаче управления, у нас тоже есть такой же генератор, как у бота, и мы можем получить первый домен. Далее пробуем его зарегать (если не получилось, – забиваем на него). Берем второй домен с последовательности; если получилось его зарегать, то вставляем маркер на главную страничку и создаем файлик temp123.txt с командой. Если когда-нибудь потеряем доступ к домену (или абуза придет, федералы отберут и т.п.), то генерируем третий домен и уже туда помещаем команду. То есть, в такой схеме перекрыть доступ к ботам невозможно. Ведь если нам закроют миллион доменов с последовательности, мы поместим команду на миллион первом, и боты все равно найдут этот домен.

Масштабируемость

Поскольку для управления мы используем обычные серваки, то быстро столкнемся с проблемами нагрузки, и сервак станет медленно, но верно загибаться. Поэтому был разработан следующий вариант - разделение ботнета на подсети. Разделение делается командами – бот стучит на сервер и читает оттуда приблизительно такую команду:

разделиться: 3001-3004

Что буквально значит: выбрать случайным образом число от значения 3001 до 3004 и использовать его для генерации последовательности доменов. Так мы разделяем ботнет на 4 части, и у каждой теперь будет своя последовательность доменов. Соответственно, они будут стучаться на разные серваки за командами. А нам остается лишь зарегистрировать 4 новых домена (по одному для каждой последовательности) и поместить команды управления на них.

Так мы сможем делить нашу систему на сколь угодно много независимых участков. И уже каждому участку задавать команду. Также мы можем дать команду слиться:

разделиться: 3001

Мы получили отличную масштабируемость, да к тому же, как побочный продукт, можем давать разные команды разным участкам, что иногда полезно.

Защита команд

Недавно в Сети проскакивала новость о том, что какие-то ученые получили доступ к ботнету на несколько дней и что-то там анализировали. Нам это вообще не нужно. А сейчас это делается очень просто, ведь федералы могут, проанализировав бота, узнать команды и домены, где боты ищут команды, а дальше передать любую команду, например, «самоуничтожиться».

Как вариант защиты, можем шифровать AES-ом, а потом переводить в BASE64. С одной стороны шифрование мощное, но если бота могут дизассемблировать и достать пароль, все наши старания пойдут прахом.

В качестве решения есть технология, которой американские власти в свое время очень боялись. Даже запретили прогу, на несколько строчек написанную на Perl'е, а люди, выражая протест, печатали на футболках код этой программы. Как ты понял - это история RSA.

С помощью RSA можно как шифровать сообщения, так и подписывать информацию, то есть гарантировать то, что именно мы подали команду. Этим и воспользуемся. Сгенерируем два ключа: паблик и приват, и в каждый бот запишем паблик-ключ. А приват-ключ будем хранить у себя.
Файл с командами теперь должен быть таким:

  1. случайная_последовательность
  2. tutamc.com
  3. 00:01 08.07.2009
  4. 23:59 09.07.2009
  5. команда 1
  6. команда ...
  7. хеш_сгенерированный_приватным_ключем

В первой строчке – случайная последовательность, что необходима для защиты от расшифровки приватного ключа. Во второй строчке размещается случайно сгенерированный домен, на котором находится команда - это защищает от несанкционированного нами копирования файла на другие участки ботнета (помним о масштабируемости). В третьей и четвертой строчке - время (промежуток, когда команда актуальна) и, собственно, список команд. Последняя строчка, сгенерированная приватным ключом, - подпись, которая гарантирует, что команда пришла именно от хозяина ботнета.
Когда бот считывает команду, то своим публичным ключом может проверить - соответствует ли текст подписи, если да - все ОК, если нет - игнорировать команду.

Этот способ позволяет полностью защитить ботнет от «врагов». Сейчас не существует способа расшифровки RSA при ключе в 2048 бит.
Полностью держать команды в открытом виде тоже не всегда интересно. Хотя никто никак повлиять не может, но от любознательных можно защититься, зашифровав файл с помощью какого-то симметрического ключа, типа AES.

При разработке бота также следует реализовать команду по смене публичного ключа в боте. Это создаст способ передачи части ботнета в другие руки, например, при продаже. Мы можем попросить покупателя сгенерировать публичный ключ – и дать нам (а приватный ключ покупатель давать не должен, что гарантирует, что мы не заберем ботнет назад). Дальше нужно отправить ботам, к примеру, такую команду:

взять_новый_публичный_ключ: "публичный ключ"

Возврат результатов

Обычно ботнетам не нужно отсылать информацию обратно, но для некоторых это обязательное условие. Опять же, возникает вопрос о безопасной передаче. Раз бот отдает список паролей, – не очень приятно, если федералы, захватив доступ к серверу, потом заблокируют акки, которые боты старательно собирали.

Для решения проблемы вновь возьмем любимый RSA. Он позволяет с помощью публичного ключа, который есть в каждом боте, зашифровать сообщения. Расшифровать сможем лишь мы, с нашим секретным приватным ключом.

Для записи информации на сервер я советую использовать POST-метод. Заранее определяем имя скрипта, которое будет принимать данные (к примеру, tttt123.php). А бот после получения команды отсылает шифрованные результаты на домен, откуда получена команда (файл tttt123.php лишь записывает файл на диск). Далее мы его забираем к себе на комп, уже там расшифровываем приватным ключом и, как водится, анализируем.

Админка

Вот мы с тобою и рассмотрели архитектуру, которая кажется идеальной. По крайней мере, я не вижу в ней уязвимых моментов. Хотя есть минус, – система сложновата в управлении. Мною была разработана удобная админка на Python'e, что автоматизирует рутину управления. К сожалению, описание уже выходит за рамки статьи, но если тебе все же интересно узнать о ее архитектуре - напиши мне на почту.

From my совесть

Как видишь, даже математика иногда (или всегда) бывает полезна, и то время, что ты потратил (или еще потратишь) на ее изучение, никогда не будет лишним. Если появились вопросы, или были не очень понятные места в статье - обращайся. И удачи в захвате мира!

Граждане!

Хочу обратиться к разным слоям общества, читающим эту статью.
К милиции: не стоить все воспринимать всерьез, это лишь картинки с моего больного сознания и судить меня нельзя :).
К создателям небольших ботнетов: советую внедрить некоторые моменты в архитектуру ботнетов. Поможет в будущем.
К профессорам и академикам: можно ли на этих идеях защитить докторскую диссертацию? Или защищаются только по теории коммунизма? :).

Псевдослучайные числа

Генератор псевдослучайных чисел (ГПСЧ, англ. Pseudorandom number generator, PRNG) — алгоритм, генерирующий последовательность чисел, элементы которой почти независимы друг от друга и подчиняются заданному распределению (обычно равномерному).

Современная информатика широко использует псевдослучайные числа в самых разных приложениях — от метода Монте-Карло и имитационного моделирования до криптографии. При этом от качества используемых ГПСЧ напрямую зависит качество получаемых результатов. Это обстоятельство подчеркивает известный афоризм Роберта Р. Кавью из ORNL (англ.): «Генерация случайных чисел слишком важна, чтобы оставлять ее на волю случая». Каждый генератор – это известная функция. Если ей дать на вход одно число, то она вернет другое. Еще можно рассматривать генератор так: мы ему на вход даем любое число, а он возвращает бесконечную последовательность чисел, что кажутся случайными.

WARNING

Вся информация предоставлена только для ознакомительных целей

INFO

RSA (буквенная аббревиатура от фамилий Rivest, Shamir и Adleman) — криптографический алгоритм с открытым ключом. RSA стал первым алгоритмом такого типа, пригодным и для шифрования, и для цифровой подписи. Алгоритм используется в большом числе криптографических приложений.

WWW

Содержание