Вірусні аналітики та дослідники комп'ютерної безпеки прагнуть зібрати якнайбільше зразків нових ботнетів. У своїх цілях вони використовують honeypot'и. Але що якщо хочеться поспостерігати за зловредом в реальних умовах? Підставити під удар свій сервер маршрутизатор? А що якщо потрібного пристрою немає? Саме ці питання наштовхнули мене на створення bhunter – інструмента для отримання доступу до вузлів бот-мереж.
Основна ідея
Існує багато способів поширення шкідливого для розширення бот-мереж: починаючи від фішингу і закінчуючи експлуатацією 0-day вразливостей. Але найпоширенішим методом досі залишається перебір паролів до SSH.
Ідея дуже проста. Якщо з якогось вузла бот-мережі здійснюється перебір паролів до сервера, то найімовірніше цей вузол сам був захоплений перебором простих паролів. Отже, щоб отримати до нього доступ, треба просто відповісти йому «взаємністю».
Саме так і працює bhunter. Слухає 22 порт (служба SSH) та збирає всі лоігни та паролі, з якими намагаються до нього підключитися. Потім, використовуючи зібрані паролі, намагається підключитися до атакуючих вузлів.
алгоритм роботи
Програму можна умовно поділити на дві основні частини, які працюють в окремих потоках. Перша - honeypot. Обробляє спроби входу, збирає унікальні логіни та паролі (у даному випадку пара логін+пароль розглядається як єдине ціле), а також додає в чергу для подальшої атаки IP-адреси, які намагалися підключитися.
Друга частина відповідає безпосередньо за атаку. При чому атака ведеться в двох режимах: BurstAttack (атака чергою) - перебір логінів і паролів із загального списку і SingleShotAttack (атака одиночними пострілами) - перебір паролів, які використовувалися вузлом, що атакувався, але ще не були додані в загальний список.
Щоб мати хоч якусь базу логінів та паролів одразу після запуску, bhunter ініціалізується списком із файлу /etc/bhunter/defaultLoginPairs.
Інтерфейс
Передбачено кілька способів запуску bhunter:
Просто командою
sudo bhunterПри такому запуску є можливість керувати bhunter'ом через його текстове меню: додавати логіни та паролі для атаки, експортувати базу логінів та паролів, вказати мету для атаки. Усі зламані вузли можна побачити у файлі /var/log/bhunter/hacked.log
Використовуючи tmux
sudo bhunter-ts # команда запуска bhunter через tmux
sudo tmux attach -t bhunter # подключаемся к сессии, в которой запущен bhunter
Tmux – термінальний мультиплексор, дуже зручний інструмент. Дозволяє в рамках одного терміналу створювати кілька вікон, а вікна розбивати на панелі. Використовуючи його можна вийти з терміналу, а потім зайти не перериваючи запущені процеси.
Скрипт bhunter-ts створює tmux-сесію та розбиває вікно на три панелі. У першій - найбільшій, знаходиться текстове меню. Верхня права містить у собі логи honeypot'а, тут можна побачити повідомлення про спроби входу на honeypot. У нижній правій панелі виводиться інформація про хід атаки на вузли бот-мереж та про успішні зломи.
Перевага цього способу над першим у тому, що ми можемо сміливо закрити термінал та повернутися до нього пізніше, при цьому bhunter не зупинить роботу. Тим, хто мало знайомий з tmux пропоную .
As a service
systemctl enable bhunter
systemctl start bhunterУ даному випадку ми включаємо автозапуск bhunter у старті системи. У цьому методі взаємодія з bhunter не передбачена, а список зламаних вузлів можна отримати з /var/log/bhunter/hacked.log
ефективність
За час роботи над bhunter мені вдалося знайти і отримати доступ до різних пристроїв: raspberry pi, маршрутизатори (особливо mikrotik), web-сервера, а одного разу ферма для майнінгу (на жаль доступ до неї був протягом дня, тому цікавої історії не вийшло ). Ось скріншот програми, на якому видно список зламаних вузлів після кількох днів роботи:
На жаль, ефективність цього інструменту не досягла моїх очікувань: bhunter може перебирати паролі до вузлів кілька днів безрезультатно, а може зламати кілька цілей за кілька годин. Але для регулярного припливу нових зразків ботнетів цього достатньо.
На ефективність впливають такі параметри як: країна, в якій розташований сервер з bhunter, хостинг і діапазон з якого виділено ip-адресу. На моєму досвіді був випадок, коли я орендував два віртуальні сервери в одного хостера, і один з них піддавався атакам з боку ботнетів у 2 рази частіше.
Баги, які я поки що не виправив
При атаці на заражені вузли в деяких ситуаціях не вдається однозначно визначити, чи підійшов пароль чи ні. Журналування таких випадків ведеться у файлі /var/log/debug.log.
Модуль Paramiko, який використовується для роботи з SSH іноді поводиться некоректно: йде в нескінченне очікування відповіді від вузла, коли намагається до нього підключитися. Я експериментував із таймерами, але потрібного результату не отримав
Над чим ще доведеться попрацювати?
Назва послуги
Згідно RFC-4253, клієнт та сервер перед установкою обмінюються назвами служб, що реалізують протокол SSH. Ця назва міститься в полі «SERVICE NAME», що міститься як у запиті з боку клієнта, так і у відповіді з боку сервера. Поле являє собою рядок, і його значення можна дізнатися, використовуючи wireshark або nmap. Ось приклад для OpenSSH:
$ nmap -p 22 ***.**.***.** -sV
Starting Nmap ...
PORT STATE SERVICE VERSION
22/tcp open ssh <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protocol 2.0)
Nmap done: 1 IP address (1 host up) scanned in 0.47 seconds
Однак у випадку з Paramiko, дане поле містить рядок виду "Paramiko Python sshd 2.4.2", що може відлякати ботнети, в які закладено "уникнення" пасток. Тому вважаю за необхідне замінити цей рядок на щось нейтральне.
Інші вектори
SSH є єдиним засобом віддаленого управління. Є ще telnet, RDP. Варто придивитися і до них.
Розширення
Було б чудово мати кілька пасток у різних країнах і централізовано збирати з них логіни, паролі та зламані вузли до загальної бази даних
Де завантажити?
На момент написання статті готова тільки тестова версія, яку можна завантажити .
Джерело: habr.com