Вирусные аналитики и исследователи компьютерной безопасности стремятся собрать как можно больше образцов новых ботнетов. В своих целях они используют honeypot'ы.… Но что если хочется понаблюдать за зловредом в реальных условиях? Подставить под удар свой сервер, маршрутизатор? А что если подходящего устройства нет? Именно эти вопросы натолкнули меня на создание bhunter — инструмента для получения доступа к узлам бот-сетей.
Существует много способов распространения вредоносного по для расширения бот-сетей: начиная от фишинга и заканчивая эксплуатацией 0-day уязвимостей. Но самым распространенным методом до сих пор остается перебор паролей к SSH.
Идея очень проста. Если с какого-то узла бот-сети осуществляется перебор паролей к вашему серверу, то вероятнее всего этот узел сам был захвачен перебором простых паролей. А значит, чтобы получить к нему доступ, надо просто ответить ему «взаимностью».
Именно так и работает bhunter. Слушает 22 порт (служба SSH) и собирает все лоигны и пароли, с которыми пытаются к нему подключиться. Затем, используя собранные пароли, пытается подключиться к атакующим узлам.
Программу можно условно разделить на 2 основные части, которые работают в отдельных потоках. Первая — honeypot. Обрабатывает попытки входа, собирает уникальные логины и пароли (в данном случае пара логин+пароль рассматривается как единое целое), а также добавляет в очередь для дальнейшей атаки IP-адреса, которые пытались подключиться.
Вторая часть отвечает непосредственно за атаку. При чем атака ведется в двух режимах: BurstAttack (атака очередью) — перебор логинов и паролей из общего списка и SingleShotAttack (атака одиночными выстрелами) — перебор паролей, которые использовались атакуемым узлом, но еще не были добавлены в общий список.
Чтобы иметь хоть какую-то базу логинов и паролей сразу после запуска, bhunter инициализируется списком из файла /etc/bhunter/defaultLoginPairs.
Предусмотрено несколько способов запуска bhunter:
При таком запуске есть возможность управлять bhunter'ом через его текстовое меню: добавлять логины и пароли для атаки, экспортировать базу логинов и паролей, указать цель для атаки. Все взломанные узлы можно увидеть в файле /var/log/bhunter/hacked.log
Tmux — терминальный мультиплексор, очень удобный инструмент. Позволяет в рамках одного терминала создавать несколько окон, а окна разбивать на панели. Используя его можно выйти из терминала а потом зайти не прерывая запущенные процессы.
Скрипт bhunter-ts создает tmux-сессию и разбивает окно на три панели. В первой — самой большой, находится текстовое меню. Верхняя правая содержит в себе логи honeypot'а, тут можно увидеть сообщения о попытках входа на honeypot. В нижней правой панели выводится информация о ходе атаки на узлы бот-сетей и об успешных взломах.
Преимущество этого способа над первым в том, что мы можем смело закрыть терминал и вернуться к нему позже, при этом bhunter не остановит работу. Тем, кто мало знаком с tmux предлагаю эту шпаргалку.
В данном случае мы включаем автозапуск 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:
Однако в случае с Paramiko, данное поле содержит строку вида «Paramiko Python sshd 2.4.2», что может отпугнуть ботнеты, в которые заложено «избегание» ловушек. Поэтому считаю необходимым заменить эту строку на что-то более нейтральное.
SSH не является единственным средством удаленного управления. Есть еще telnet, rdp. Стоит присмотреться и к ним.
Было бы здорово иметь несколько ловушек в разных странах и централизовано собирать с них логины, пароли и взломанные узлы в общую базу данных
На момент написания статьи готова только тестовая версия, которую можно скачать из репозитория на Github.
Основная идея
Существует много способов распространения вредоносного по для расширения бот-сетей: начиная от фишинга и заканчивая эксплуатацией 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», что может отпугнуть ботнеты, в которые заложено «избегание» ловушек. Поэтому считаю необходимым заменить эту строку на что-то более нейтральное.
Другие вектора
SSH не является единственным средством удаленного управления. Есть еще telnet, rdp. Стоит присмотреться и к ним.
Расширение
Было бы здорово иметь несколько ловушек в разных странах и централизовано собирать с них логины, пароли и взломанные узлы в общую базу данных
Где скачать?
На момент написания статьи готова только тестовая версия, которую можно скачать из репозитория на Github.
knutov
Самое интересное то и не рассказано )
Получилось ли таким методом получить доступ к какому-то ботнету?
DVoropaev Автор
Да, вот примеры: раз, два.
DVoropaev Автор
добавил в статью