Вірусныя аналітыкі і даследнікі кампутарнай бяспекі імкнуцца сабраць як мага больш узораў новых ботнэтаў. У сваіх мэтах яны выкарыстоўваюць 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 часам паводзіць сябе некарэктна: сыходзіць у бясконцае чаканне адказу ад вузла, калі спрабуе да яго далучыцца. Я эксперыментаваў з таймерамі, але патрэбнага выніку не атрымаў

Над чым яшчэ трэба папрацаваць?

служба імёнаў

Згодна з 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.

Крыніца: habr.com