1
  1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.
Приветствуем вас,Гость, на форуме IFUD.WS. Обязательно рекомендуется к прочтению правила форума http://ifud.ws/threads/obnovleno-pravila-foruma.7759

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

Тема в разделе "Чужие", создана пользователем polimorf, 16 июн 2014.

  1. TopicStarter Overlay
    polimorf

    polimorf

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

    Два года назад моя «аналитическая» группа получила заказ на разработку идеальной архитектуры большого ботнета. Месяц ушел на изучение существующих решений и продумывание своих вариантов. То, что получилось, было реализовано и сейчас отлично работает :). С заказчиком был договор, что 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 лишь записывает файл на диск). Далее мы его забираем к себе на комп, уже там расшифровываем приватным ключом и, как водится, анализируем.

    Админка

    Вот мы с тобою и рассмотрели архитектуру, которая кажется идеальной. По крайней мере, я не вижу в ней уязвимых моментов. Хотя есть минус, – система сложновата в управлении.

    Взято из журнала "Хакер"
     
    • Like Like x 4
    Метки:

Поделиться этой страницей

Загрузка...