Історія про дослідження та розробку в 3-х частинах. Частина 1 – дослідницька.
Буків багато – користі ще більше.
Постановка завдання
Під час проведення пентестів та RedTeam кампаній не завжди вдається скористатися штатними засобами Замовників, такими як VPN, RDP, Citrix тощо. як закріплення для заходу у внутрішню мережу. Десь штатний VPN працює по MFA і як другий фактор використовується залізний токен, десь він жорстоко моніториться і наш вхід по VPN відразу ж стає видно, як кажуть — з усіма витікаючими, а десь таких засобів просто немає.
У подібних випадках постійно доводиться робити так звані «зворотні тунелі» — з'єднання з внутрішньої мережі до зовнішнього ресурсу або сервера, який ми контролюємо. Усередині такого тунелю ми можемо працювати з внутрішніми ресурсами Замовників.
Існує кілька різновидів таких зворотних тунелів. Найвідоміший з них, звичайно ж, Meterpreter. Також великим попитом у народних хакерських масах користуються SSH-тунелі зі зворотним прокиданням портів. Засобів здійснення зворотного тунелювання досить багато і багато з них добре вивчені та описані.
Звичайно, зі свого боку розробники захисних рішень не стоять осторонь і активно детектують подібні дії.
Наприклад, MSF-сесії успішно детектуються сучасними IPS від Cisco або Positive Tech, а зворотний SSH-тунель можна задетектувати практично будь-яким більш-менш нормальним фаєрволом.
Отже, для того, щоб залишитися непоміченим у гарній RedTeam кампанії, нам необхідно будувати зворотний тунель нестандартними засобами і максимально близько підлаштовуватися під реальний режим роботи мережі.
Спробуємо знайти або винайти щось подібне.
Перш ніж щось винаходити, треба зрозуміти, якого результату ми хочемо досягти, які функції має виконувати наша розробка. Які будуть вимоги до тунелю, щоб ми могли працювати в режимі максимальної скритності?
Зрозуміло, що для кожного випадку такі вимоги можуть сильно відрізнятись, але за досвідом роботи можна виділити основні:
- робота на Windows-7-10. Так як у більшості корпоративних мереж використовується саме вінда;
- клієнт з'єднується з сервером SSL для виключення тупого прослуховування засобами ips;
- при з'єднанні клієнт має підтримувати роботу через проксі-сервер з авторизацією, т.к. у багатьох компаніях вихід в інтернет відбувається через проксі. Насправді клієнтська машина може про це навіть нічого і не знати, а проксі використовується в транспарентному режимі. Але такий функціонал ми маємо закласти;
- клієнтська частина має бути лаконічна і портабельна;
Зрозуміло, що для роботи в мережі Замовника на клієнтській машині можна встановити OpenVPN і підняти повноцінний тунель до свого сервера (добре, що клієнти openvpn вміють працювати через проксі). Але, по-перше, це не завжди вийде, тому що ми можемо не бути там локальними адмінами, а по-друге, це наробить так багато шуму, що порядний SIEM або HIPS відразу на нас «настукає куди треба». В ідеалі наш клієнт повинен бути так званою inline командою, як, наприклад, реалізовано багато bash-шеллів, і запускатися через командний рядок, наприклад, при виконанні команд з word-макросу. - наш тунель має бути багатопоточним і підтримувати безліч з'єднань одночасно;
- з'єднання клієнт-сервер повинно мати будь-яку авторизацію, щоб тунель встановлювався тільки для нашого клієнта, а не для всіх, хто прийде до нас на сервер за вказаною адресою та портом. В ідеалі, для «сторонніх користувачів» має відкриватися лендинг-сторінка з котиками або професійно тематикою, пов'язаною з вихідним доменом.
Наприклад, якщо Замовником виступає медична організація, то для адміністратора інформаційної безпеки, який вирішив перевірити ресурс, на який звертався співробітник клініки, має відкритися сторінка з фармацевтичними товарами, вікіпедія з описом діагнозу чи блог доктора Комаровського тощо.
Аналіз існуючих інструментів
Перш ніж винаходити свій велосипед, необхідно зробити аналіз існуючих велосипедів і зрозуміти, чи справді воно нам треба і, ймовірно, не тільки ми задумалися про необхідність такого функціонального велосипеда.
Гуглення в інтернеті (гуглим ми начебто нормально), а також пошук по гітхабу за ключовими словами «reverse socks» не дав особливо багато результатів. В основному все зводиться до побудови ssh-тунелів зі зворотним прокиданням портів і всього, що з цим пов'язано. Крім SSH-тунелів можна виділити кілька рішень:
Давня реалізація зворотного тунелю від хлопців із Лабораторії Касперського. За назвою зрозуміло, навіщо призначений цей скрипт. Реалізовано на Python 2.7, тунель працює в cleartext режимі (як модно зараз говорити – привіт РКН)
Ще одна реалізація на пітоні, так само в чистомутексті, але можливостей більше. Написаний у вигляді модуля і є API для інтеграції рішення у свої проекти.
Перше посилання – початкова версія реалізації реверсу соксу на голанзі (не підтримується розробником).
Друге посилання — вже наше доопрацювання з додатковими фішками, також на голанзі. У нашій версії ми реалізували SSL, роботу через проксі з NTLM-авторизацією, авторизацію на клієнті, лендинг-сторінку при неправильному паролі (вірніше — редирект на лендинг-сторінку), багатопотоковий режим (тобто з тунелем можуть працювати кілька людей одночасно) , систему пінгів клієнта щодо того — живий він чи ні.
Реалізація зворотного соксу від наших китайських друзів на пітоні. Там же для лінивих і безсмертних лежить вже готовий бінар (exe), зібраний китайцями і готовий до використання. Тут тільки китайський бог знає, що в цьому бінарі може бути ще, крім основного функціонала, так що використовуйте на свій страх і ризик.
Цікавий проект на С++ для реалізації зворотного соксу і не тільки. Крім зворотного тунелю, може робити прокидання портів, створення командного шелла тощо.
MSF meterpreter
Тут, як кажуть, без коментарів. Всі більш-менш освічені хакери чудово знайомі з цією штукою і розуміють, наскільки легко її виявляють засоби захисту.
Всі описані вище інструменти працюють за схожою технологією: на машині всередині мережі запускається заздалегідь підготовлений виконуваний бінарний модуль, який встановлює з'єднання із зовнішнім сервером. На сервері запускається SOCKS4/5 сервер, який приймає підключення та транслює їх на клієнта.
Недоліком всіх перелічених вище інструментів є те, що або на клієнтській машині необхідний встановлений Python або Golang (часто ви зустрічали встановлений Python на машинах, наприклад, директора компанії або офісних працівників?), або на цю машину необхідно тягнути заздалегідь зібраний бінар (фактично python і скрипт в одному флаконі) і запускати цей бінар уже там. А завантаження exe з наступним його запуском – це ще та сигнатура для місцевого антивірусу чи HIPS.
Загалом висновок напрошується сам собою — нам потрібне рішення на powershell. Зараз у нас полетять помідори – мовляв, powershell – це вже все побито, він моніториться, блокується і т.д. і т.п. Насправді далеко не скрізь. Відповідально заявляємо. До речі, існує безліч способів обійти блокування (тут знову модна фраза про привіт РКН 🙂), починаючи від тупого перейменування powershell.exe -> cmdd.exe і закінчуючи powerdll і т.п.
Починаємо винаходити
Зрозуміло, що спершу ми подивимося в гугл і… не знайдемо нічого по цій темі (якщо хтось знайшов — кидайте посилання в коментарі). Є тільки Socks5 на powershell, але це звичайний "прямий" сокс, що має ряд своїх недоліків (про них поговоримо пізніше). Можна, звичайно, легким рухом руки перетворити його на зворотний, але це буде тільки однопотоковий сокс, що для нас не зовсім те, що треба.
Отже, ми не знайшли нічого готового, тому нам доведеться таки винайти свій велосипед. За основу нашого велосипеда ми візьмемо зворотного соксу на голанзі, а клієнта до нього реалізуємо на powershell.
RSocksTun
Отже, як же працює rsockstun?
В основі роботи RsocksTun (далі за текстом - rs) лежать два програмні компоненти - Yamux і Socks5 сервер. Socks5 сервер це звичайний локальний socks5, він запускається на клієнті. А мультиплексування з'єднань до нього (пам'ятаєте про багатопоточність?) Забезпечується за допомогою yamux (). Така схема дозволяє запускати кілька клієнтських socks5 серверів і розподіляти зовнішні підключення до них, прокидаючи їх через одне єдине TCP-з'єднання (майже як у meterpreter) від клієнта до сервера, реалізуючи тим самим багатопоточний режим, без якого нам просто не вдасться повноцінно працювати у внутрішній мережі.
Суть роботи yamux'а полягає в тому, що він вводить додатковий мережевий рівень стриму, реалізуючи його у вигляді 12-байтного заголовка для кожного пакета. (Тут ми навмисно використовуємо слово "стрім", а не потік, щоб не плутати читача з програмним потоком "thread" - це поняття ми так само використовуватимемо в даній статті). Всередині yamux заголовка містяться номер стриму, прапори для встановлення/завершення стриму, кількість байт, що передаються, розмір вікна передачі.
Крім установки/завершення стриму в yamux реалізований механізм keepalive'ів, що дозволяє відстежувати працездатність встановленого каналу зв'язку. Робота механізму keeplive-повідомлень налаштовується під час створення Yamux-сесії. Власне, з налаштувань там тільки два параметри: enable/disable і періодичність відсилання пакетів в секундах. Keepalive-повідомлення може відсилати yamux-сервер, так і yamux-клієнт. При отриманні keepalive-повідомлення віддалена сторона зобов'язана відповісти на нього посилкою точно такого ж ідентифікатора повідомлення (фактично числа), який вона прийняла. Загалом, keepalive це той же пінг, тільки для yamux.
Детально вся техніка роботи мультиплексора: типи пакетів, прапори установки та завершення з'єднань механізм передачі даних описана в до yamux.
Висновок до першої частини
Отже, у першій частині статті ми познайомилися з деяким інструментарієм з організації зворотних тунелів, подивилися на їх переваги та недоліки, вивчили механізм роботи Yamux мультиплексора та описали основні вимоги до новоствореного powershell-модуля. У наступній частині ми займемося розробкою самого модуля практично з нуля. Далі буде. Не перемикайтеся 🙂
Джерело: habr.com