Захист великих ботнет-мереж
Великі ботнети - закрита тема, на яку не те що в паблику не розмовляють, а навіть у надсекретному приваті мало цікавих обговорень. І одна з причин - обмежена кількість таких бот-мереж (адже ми говоримо про сотні тисяч заражених комп'ютерів!). Але, незважаючи на відносну закритість цієї інформації, я тобі розповім абсолютно все найцікавіше.
Два роки тому моя аналітична група отримала замовлення на розробку ідеальної архітектури великого ботнету. Місяць пішов на вивчення існуючих рішень та продумування своїх варіантів. Те, що вийшло, було реалізовано і зараз добре працює :). Із замовником був договір, що 2 роки ми не поширюватимемо цю інформацію. Зараз час вийшов, і ти будеш перший, хто, можливо, зможе реалізувати архітектуру для свого ботнета. У статті ми розглянемо:
Умови існування великих ботнетів Утримання контролю Генерацію доменів Масштабованість Можливість поділу Подання команд, їх захист Повернення результатів
Ох, непросте життя у великих ботнетів.
Якщо в тебе ботне на 1000 або 10.000 комп'ютерів, то, очевидно, з ним багато проблем. Але всі вони здаються нікчемними порівняно з траблами, коли розмір мережі перевищив цифру 100.000. На тебе і твій ботнет відкриють справжнє полювання антивірусні компанії, правоохоронні органи та звичайні генії, яким від нефіг робити захочеться подивитися кишки твого бота. Та й «колеги» не дадуть спокою, – усіма засобами намагатимуться викрасти ботнет. На тебе, звичайно, чекає слава, і може навіть покажуть по ТБ, але цей піар здатний повністю вбити весь бізнес, якщо архітектура ботнета виявиться поганою.
Це війна, і в ній можна перемогти, лише використавшиостанні досягнення у науці. Щоб убити твій ботнет, «вороги» будуть аналізувати його, дивитися, що і як він робить, та ще й дизасемблювати код. І ніякі антиналагоджувальні прийоми, багаторазова поліморфна криптівка та інше не допоможуть закрити від них начинки бота.
З цією проблемою можна боротися, дотримуючись першого правила ботнетів: «Потрібно будувати ботів, вважаючи, що вся інформація про них буде повністю відкрита».
Друга проблема виникає з масштабом ботнету. Величезна кількість ботів не витримає жоден сервак, а поставити кластер з розподільниками навантаження у тебе не вийде, тому що це дуже складно і довго. Та й навіть якщо все буде готове, – прийдуть федерали (я так називатиму ФБР, ФСБ, СБУ тощо) і швиденько конфіскують. З цього народжується друге правило: «Ботнет повинен керуватися звичайними серверами». Приступимо до розгляду архітектури, що відповідає цим правилам.
Спосіб спілкування з ботами – це «хребет» ботнета. Раніше дуже популярною була передача команд через IRC, де боти заходили до заздалегідь визначених кімнат і чекали, що хтось передасть їм команду. Ну, цей метод тільки археологи зараз використовують, і про безліч його проблем навіть не хочеться говорити. Зараз найчастіше користується схема p2p або web.
p2p – досить цікава схема, яка має право на життя при великих ботнетах. У ній перевагою служить те, що навантаження передачі команд лежить на самих ботах. Мінусів у ній також вистачає:
Складність архітектури Нестабільність мережі «Палевність» відкриття портів Складність контролю Складність віддачі результатів від ботів І багато іншого. Управління ботнетом по web'у – поки що найідеальніший варіант. Наприклад, візьмемо Zeus. У нього в конфізі прописуємо основний домен, де адмінка ідодатковий домен (якщо перший сервак накриється). Але якщо завтра роботів буде багато, вони легко покладуть сервак, а якщо сервак і витримає, то післязавтра прийдуть федерали і прикриють як основний, так і додатковий домен, після чого відновити управління не вдасться. Ця схема абсолютно не підходить для великих ботнетів.
Як у відомому фільмі легким рухом руки штани перетворюються на шорти, так і ми можемо марну схему перетворити на ідеальну. І ключова ідея – у динамічній генерації доменів, через які бот спілкуватиметься. Генерувати домени будемо, використовуючи генератор псевдовипадкових чисел (ГПСЧ). Якщо ти не знайомий з ним, подивися врізку - там я все коротко описав. Для нас важливою є одна фішка: якщо на вхід генератора дати число 1234, генератор може повернути: 6452, 12, 761 і т.д. І скільки б разів і на якому комп'ютері це не повторювали, завжди буде послідовність однакова.
Виходячи з цього, ми можемо написати функцію, що використовуватиме генератор псевдовипадкових чисел, і якщо передати якесь число на генератор, він зможе згенерувати випадкову нескінченну послідовність доменів. Нам лише необхідно для синхронізації всім роботам передати однакове початкове число. З урахуванням усіх зауважень принцип роботи буде таким:
Генеруємо псевдовипадковий домен Перевіряємо, чи є на головній сторінці домену якийсь певний текст - маркер Якщо маркера немає, - повертаємося до першого пункту Якщо маркер є, то отримуємо команду для виконання Закінчення ж доменів не генерується випадково, а вибираються з масиву, який може містити як звичайні закінчення, так і закінчення безкоштовних хостингів. Чим список буде більше – тим краще. Він може виглядати так:
Де ".ho.ua" - звичайний безкоштовний хостинг. Якщо вінпотрапить у послідовність, то нам навіть не потрібно буде купувати домен, а просто безкоштовно собі заріжемо піддомен. Цього буде досить.
Робот, після перевірки маркера, повинен вимагати певний текстовий файлик, наприклад, temp123.txt, і звідти брати команду для виконання. 5. Говорячи про завдання управління, у нас теж є такий же генератор, як у бота, і ми можемо отримати перший домен. Далі пробуємо його зарегати (якщо не вийшло – забиваємо на нього). Беремо другий домен із послідовності; якщо вдалося його зареєструвати, то вставляємо маркер на головну сторінку і створюємо файл temp123.txt з командою. Якщо коли-небудь втратимо доступ до домену (або прийде абуза, федерали відберуть і т.п.), то генеруємо третій домен і вже туди поміщаємо команду. Тобто в такій схемі перекрити доступ до ботів неможливо. Адже якщо нам закриють мільйон доменів із послідовності, ми помістимо команду на мільйон першому, і боти все одно знайдуть цей домен.
Оскільки для управління ми використовуємо звичайні серваки, то швидко зіткнемося з проблемами навантаження, і сервак стане повільно, але загинатися. Тому був розроблений наступний варіант – поділ ботнету на підмережі. Поділ робиться командами - бот стукає на сервер і читає звідти приблизно таку команду:
Що буквально означає: вибрати випадково число від значення 3001 до 3004 і використовувати його для генерації послідовності доменів. Так ми поділяємо ботнет на 4 частини, і кожна тепер матиме свою послідовність доменів. Відповідно, вони стукатимуть на різні серваки за командами. А нам залишається лише зареєструвати 4 нових домени (по одному для кожної послідовності) та помістити команди управління на них.
Так ми зможемо ділити нашу систему на скільки завгодно багатонезалежних ділянок. І вже кожній ділянці задаватиме команду. Також ми можемо дати команду злитися:
Ми отримали відмінну масштабованість, та ще й, як побічний продукт, можемо давати різні команди різним ділянкам, що іноді корисно.
Нещодавно в Мережі проскакувала новина про те, що якісь вчені отримали доступ до ботнету на кілька днів і там щось аналізували. Нам це взагалі не потрібне. А зараз це робиться дуже просто, адже федерали можуть, проаналізувавши бота, дізнатися про команди та домени, де боти шукають команди, а далі передати будь-яку команду, наприклад, «самознищитись».
Як варіант захисту можемо шифрувати AES-ом, а потім переводити в BASE64. З одного боку шифрування потужне, але якщо бота можуть дизассемблювати та дістати пароль, всі наші старання підуть прахом.
Як рішення є технологія, якої американська влада свого часу дуже боялася. Навіть заборонили прогу, на кілька рядків написану на Perl'і, а люди, висловлюючи протест, друкували на футболках код цієї програми. Як ти зрозумів – це історія RSA.
За допомогою RSA можна як шифрувати повідомлення, так і підписувати інформацію, тобто гарантувати те, що ми подали команду. Цим і скористаємось. Згенеруємо два ключі: паблік і приват, і кожен бот запишемо паблік-ключ. А приват-ключ зберігатимемо у себе. Файл з командами тепер має бути таким:
Цей спосіб дозволяє повністю захистити ботнет від ворогів. Зараз немає способу розшифровки RSA при ключі в 2048 біт. Повністю тримати команди у відкритому вигляді теж не завжди цікаво. Хоча ніхто ніяк не може вплинути, але від допитливих можна захиститися, зашифрувавши файл за допомогою якогось симетричного ключа, типу AES.
Під час розробки бота також слід продатикоманду зі зміни публічного ключа у боті. Це створить спосіб передачі частини ботнета до інших рук, наприклад, під час продажу. Ми можемо попросити покупця згенерувати публічний ключ - і дати нам (а приватний ключ покупець давати не повинен, що гарантує, що ми не заберемо ботнет назад). Далі потрібно відправити ботам, наприклад, таку команду:
взяти_новий_публічний_ключ: "публічний ключ"
Зазвичай ботнетам не потрібно надсилати інформацію назад, але для деяких це обов'язкова умова. Знову ж таки, виникає питання про безпечну передачу. Раз бот віддає список паролів, - не дуже приємно, якщо федерали, захопивши доступ до сервера, потім заблокують аккі, які боти старанно збирали.
Для вирішення проблеми знову візьмемо улюблений RSA. Він дозволяє за допомогою публічного ключа, який є в кожному роботі, зашифрувати повідомлення. Розшифрувати зможемо лише ми, з нашим секретним приватним ключем.
Для запису інформації на сервер я рекомендую використовувати POST-метод. Заздалегідь визначаємо ім'я скрипта, яке прийматиме дані (наприклад, tttt123.php). А бот після отримання команди надсилає шифровані результати на домен, звідки отримана команда (файл tttt123.php лише записує файл на диск). Далі ми його забираємо до себе на комп'ютер, вже там розшифровуємо приватним ключем і, як водиться, аналізуємо.
Ось ми з тобою розглянули архітектуру, яка здається ідеальною. Принаймні я не бачу в ній уразливих моментів. Хоча є мінус, – система важкувата в управлінні.