Гісторыя аб даследаванні і распрацоўцы ў 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 рэжыме (як модна зараз казаць – прывітанне РКН)
Яшчэ адна рэалізацыя на пітоне, гэтак жа ў 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