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