Вирусни анализатори и изследователи на компютърна сигурност се стремят да съберат колкото се може повече образци на нови ботнетове. За целите си те използват 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 предлагам тази шпаргалка.

Като услуга

systemctl enable bhunter
systemctl start bhunter

В този случай включваме автоматичното стартиране на bhunter при старт на системата. В този метод взаимодействие с bhunter не е предвидено, а списъкът с хакнати възли може да се получи от /var/log/bhunter/hacked.log

Ефективност

По време на работата си върху bhunter успях да намеря и получа достъп до напълно различни устройства: raspberry pi, маршрутизатори (особено mikrotik), уеб-сервери, а веднъж и ферма за майнинг (за съжаление достъпът до нея беше в течение на деня, така че интересната история не се получи). Ето снимка на програмата, на която се вижда списък с хакнати възли след няколко дни работа:

За съжаление, ефективността на този инструмент не достигна моите очаквания: bhunter може да пробива пароли на възли в продължение на няколко дни безрезултатно, а може и да хакне няколко цели за няколко часа. Но за регулярния приток на нови образци на ботнети това е достатъчно.

Ефективността се влияе от параметри като: страната, в която се намира сървърът с bhunter, хостингът и диапазонът, от който е предоставен IP адресът. По мой опит имаше случай, когато наех два виртуални сървъра от един хостинг провайдер, и единият от тях беше подложен на атаки от ботнети два пъти по-често.

Бъгове, които все още не съм поправил

При атака на заразени възли в някои ситуации не може категорично да се определи дали паролата е подходяща или не. Логването на такива случаи се води в файла /var/log/debug.log.

Модулът Paramiko, който се използва за работа с SSH, понякога се държи некоректно: влиза в безкрайно изчакване на отговор от възела, когато се опитва да се свърже с него. Плюс експериментирах с таймери, но не получих желания резултат.

Какво още остава да се разработи?

Име на услугата

Съгласно RFC-4253, клиентът и сървърът обменят имена на услуги, реализиращи протокола SSH преди установяване на връзка. Това име се съдържа в полето "SERVICE NAME", присъстващо както в запитването от клиента, така и в отговора от сървъра. Полето представлява низ, и неговата стойност може да се определи с помощта на wireshark или nmap. Ето пример за OpenSSH:

$ nmap -p 22 ***.**.***.** -sV
Започване на Nmap ...
ПОРТ   СЪСТОЯНИЕ УСЛУГА ВЕРСИЯ
22/tcp отворен  ssh     <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (протокол 2.0)
Nmap приключи: 1 IP адрес (1 хост активен) сканиран за 0.47 секунди

Въпреки това, в случая с Paramiko, това поле съдържа низ от вида "Paramiko Python sshd 2.4.2", което може да отблъсне ботнети, в които е заложено "избягване" на капани. Затова считам за необходимо да заменя този низ с нещо по-нейтрално.