- Специальный корреспондент
Вирусные аналитики и исследователи компьютерной безопасности стремятся собрать как можно больше образцов новых ботнетов. В своих целях они используют 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
Баги, которые я пока не исправил
При атаке на зараженные узлы в некоторых ситуациях не удается однозначно определить подошел пароль или нет. Журналирование таких случаев ведется в файле /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. Стоит присмотреться и к ним.
Расширение
Было бы здорово иметь несколько ловушек в разных странах и централизовано собирать с них логины, пароли и взломанные узлы в общую базу данных
Где скачать?
На момент написания статьи готова только тестовая версия, которую можно скачать из .
Основная идея
Существует много способов распространения вредоносного по для расширения бот-сетей: начиная от фишинга и заканчивая эксплуатацией 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
Баги, которые я пока не исправил
При атаке на зараженные узлы в некоторых ситуациях не удается однозначно определить подошел пароль или нет. Журналирование таких случаев ведется в файле /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. Стоит присмотреться и к ним.
Расширение
Было бы здорово иметь несколько ловушек в разных странах и централизовано собирать с них логины, пароли и взломанные узлы в общую базу данных
Где скачать?
На момент написания статьи готова только тестовая версия, которую можно скачать из .
