Вирусные аналитики и исследователи компьютерной безопасности стремятся собрать как можно больше образцов новых ботнетов. В своих целях они используют honeypot’ы.… Но что если хочется понаблюдать за зловредом в реальных условиях? Подставить под удар свой сервер, маршрутизатор? А что если подходящего устройства нет? Именно эти вопросы натолкнули меня на создание bhunter — инструмента для получения доступа к узлам бот-сетей.

Основная идея

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

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

Именно так и работает bhunter. Слушает 22 порт (служба SSH) и собирает все лоигны и пароли, с которыми пытаются к нему подключиться. Затем, используя собранные пароли, пытается подключиться к атакующим узлам.

Алгоритм работы

Программу можно условно разделить на 2 основные части, которые работают в отдельных потоках. Первая — 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 иногда ведет себя некорректно: уходит в бесконечное ожидание ответа от узла, когда пытается к нему подключиться. Я экспериментировал с таймерами, но нужного результата не получил

Над чем еще предстоит поработать?

Service name

Согласно 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», что может отпугнуть ботнеты, в которые заложено «избегание» ловушек. Поэтому считаю необходимым заменить эту строку на что-то более нейтральное.