Stāsts par izpēti un attīstību 3 daļās. 1. daļa — izpētes.
Burtu ir daudz — labuma vēl vairāk.
Uzdevuma formulēšana
Veicot pentesta un RedTeam kampaņas, ne vienmēr ir iespējams izmantot klientu standarta resursus, piemēram, VPN, RDP, Citrix utt., kā piekļuvi iekšējai tīklam. Dažos gadījumos standarta VPN darbojas ar MFA, un kā otro faktoru tiek izmantots aparatūras tokens, citos tiek veikta stingra uzraudzība, un mūsu piekļuves mēģinājums uz VPN uzreiz kļūst redzams, kā saka — ar visām sekām, bet dažviet šādu līdzekļu vienkārši nav.
Tādās situācijās nepārtraukti nākas veidot tā sauktos "atpakaļtūneļus" — savienojumus no iekšējā tīkla uz ārējiem resursiem vai serveriem, kurus kontrolējam mēs. Šā tūra iekšienē mēs jau varam strādāt ar klientu iekšējiem resursiem.
Pastāv vairākas šādu atpakaļtuneļu variācijas. Vispazīstamākais no tiem, protams, ir Meterpreter. Tāpat liela pieprasījuma dēļ hakeru vidū ir SSH tuneļi ar atpakaļvērstu portu pārsūtīšanu. Rīku, lai veiktu atpakaļtuneļošanu, ir daudz, un daudzi no tiem ir labi izpētīti un aprakstīti.
Protams, savā pusē aizsardzības risinājumu izstrādātāji nenovērš uzmanību un aktīvi atklāj šādas darbības.
Piemēram, MSF sesijas veiksmīgi atklāj mūsdienu IPS no Cisco vai Positive Tech, bet atpakaļ SSH tuneļa detektēšana ir iespējama praktiski ar jebkuru normālu ugunsmūri.
Tādējādi, lai paliktu nepamanītiem labā RedTeam kampaņā — mums ir nepieciešams būvēt atpakaļtuneļus ar nestandarta rīkiem un maksimāli pielāgoties reālajai tīkla darbībai.
Mēģināsim atrast vai izdomāt ko līdzīgu.
Pirms kaut ko izdomājam, mums jāizprot, kāda rezultāta mēs vēlamies sasniegt, kādas funkcijas jāveic mūsu izstrādei. Kādi būs prasības tunelim, lai mēs varētu darboties maksimālā slepenībā?
Ir skaidrs, ka katram gadījumam šādas prasības var atšķirties, bet pēc darba pieredzes var izdalīt galvenās:
- darbs uz Windows-7-10 operētājsistēmas. Jo lielākajā daļā korporatīvo tīklu tiek izmantota tieši Windows;
- Klients izveido savienojumu ar serveri, izmantojot SSL, lai novērstu datu noklausīšanos ar ips palīdzību;
- Savienojuma izveidei klientam jāturpina darbs caur autorizētu starpserveri, jo daudzas kompānijas piekļūst internetam caur proxy. Patiesībā klienta mašīna par to var neko nezināt, bet proxy darbojas caur caurspīdīgu režīmu. Tomēr šādai funkcionalitātei mums jābūt iekļautai;
- Klienta daļai jābūt lakoniskai un pārnēsājamai;
Acīmredzot, lai strādātu iekšējā klienta tīklā, klienta mašīnā var instalēt OpenVPN un izveidot pilnvērtīgu tuneli uz savu serveri (priecājamies, ka OpenVPN klienti spēj darboties caur proxy). Bet, pirmkārt, tas ne vienmēr izdosies, jo mēs varam nebūt vietējie administratori, un, otrkārt, tas radīs tik daudz troksni, ka kārtīgs SIEM vai HIPS nekavējoties par to ziņos. Ideāli, mūsu klientam jābūt tā sauktajai inline komandai, kā to īsteno daudzi bash shell; tam jābūt iespējami izpildāmam caur komandrindu, piemēram, izpildot komandas no Word makro. - Mūsu tunelim jābūt daudzplūsmam un jāatbalsta vairāku savienojumu izveide vienlaicīgi;
- Savienojumam starp klientu un serveri jāietver kāda veida autorizācija, lai tunelis tiktu izveidots tikai mūsu klientam, nevis visiem, kas piekļūs mūsu serverim norādītajā adresē un portā. Ideālā gadījumā "trešām personām" jāatver mērķlapas ar kaķīšiem vai profesionālu tematiku, kas saistīta ar izcelsmes domēnu.
Piemēram, ja pasūtītājs ir medicīnas organizācija, tad informācijas drošības administratoram, kurš vēlējās pārbaudīt resursu, uz kuru saistījās klīnikas darbinieks, jāatver lapa ar farmaceitiskiem precēm, Wikipedia ar diagnozes aprakstu vai Dr. Komarovska blogs u.t.t.
Esošo rīku analīze
Pirms izgudrot savu velosipēdu — jāveic esošo velosipēdu analīze un jāsaprot, vai mums to patiešām vajag, jo iespējams, ka ne tikai mēs esam domājuši par šādu funkcionālu velosipēdu.
Meklējot internetā (mēs acīmredzot meklējam normāli), kā arī meklējot GitHubā ar atslēgvārdiem „reverse socks”, netika atrasti daudzi rezultāti. Lielākoties viss ir saistīts ar SSH tunelēšanu ar reverso portu pārsūtīšanu un visu, kas ar to saistīts. Papildus SSH tunelēm var izcelt vairākas risinājumu iespējas:
Vecais reversā tunelēšanas risinājums no Kaspersky laboratorijas puišiem. No nosaukuma skaidri redzams, kam paredzēts šis skripts. Realizēts Python 2.7, tunelis darbojas cleartext režīmā (kā tagad modē saka – sveiki, RKN)
Vēl viena realizācija Pythonā, arī cleartext, bet ar vairāk iespējām. Uzrakstīts kā modulis un ir API, lai integrētu risinājumu savos projektos.
Pirmais saite – sākotnējā versija reversā socka realizācijai golangā (to neatbalsta izstrādātājs).
Otrais saite – jau mūsu izstrādājums ar papildu funkcijām, arī golangā. Mūsu versijā mēs realizējām SSL, darbu caur proksi ar NTLM autorizāciju, autorizāciju klientā, nosūtīšanas lapu nepareiza parole gadījumā (precīzāk – pāradresācija uz nosūtīšanas lapu), daudzuzdevumu režīmu (t.i., ar tuneli var strādāt vairāki cilvēki vienlaikus), klienta ping sistēmu, lai pārbaudītu – vai tas ir dzīvs vai nav.
Reversā socka realizācija no mūsu „ķīniešu draugiem” Pythonā. Turpat tiem, kas ir slinki un „neievainojami”, ir jau gatavs binārais fails (exe), ko sagatavojuši ķīnieši un ko var izmantot. Šajā failā tikai Ķīnas dievs zina, kas varētu būt vēl klāt, izņemot pamata funkcionalitāti, tāpēc izmantojiet to uz savu risku.
Pietiekami interesants projekts C++ reversā socka realizācijai un ne tikai. Papildus reversajam tunelim tas var veikt portu pārsūtīšanu, komandu šell izveidi utt.
MSF meterpreter
Šeit, kā saka, bez komentāriem. Visi kaut cik izglītoti hakeri lieliski pazīst šo lietu un saprot, cik viegli to atklāj drošības līdzekļi.
Visi iepriekšminētie rīki darbojas līdzīgā tehnoloģijā: iekšējā tīkla mašīnā tiek palaists iepriekš sagatavots izpildāms binārais modulis, kas izveido savienojumu ar ārējo serveri. Serverī tiek palaists SOCKS4/5 serveris, kas pieņem savienojumus un tos pārsūta uz klientu.
Visu iepriekš uzskaitīto rīku trūkums ir tas, ka vai nu klienta mašīnā ir jābūt instalētam Python vai Golang (cik bieži jūs esat sastapuši uzstādītu Python uz uzņēmuma direktora vai biroja darbinieku datoriem?), vai nu uz šo datoru jānes iepriekš sagatavots binārs (faktiski python un skripts vienā flakonā) un jāpalaiž šis binārs tur. Un .exe fails ar sekojošu palaišanu — tas ir vēl viens paraugs vietējā antivīrusa vai HIPS.
Kopumā secinājums ir acīmredzams — mums ir vajadzīgs risinājums uz PowerShell. Tagad mūs apmētās ar tomātiem — jo PowerShell ir jau viss novecojis, to uzrauga, bloķē utt. Patiesībā — tas ne visur tā ir. Atbildīgi paziņojam. Starp citu, pastāv daudz veidu, kā apiet blokādes (atkal mode frāze par sveicienu RKN 🙂), sākot no primitīvas pārdēvēšanas powershell.exe -> cmdd.exe un beidzot ar powerdll utt.
Sākam izdomāt
Saprotams, ka vispirms mēs meklēsim Google un... neatradīsim absolūti neko šajā tēmā (ja kāds ir atradis — lūdzu, dalieties ar saites komentāros). Ir tikai Socks5 uz PowerShell, bet tas ir parasts „tiešais” socks, kam ir vairākas ierobežojumus (par tiem runāsim vēlāk). Protams, ir iespējams viegli pārvērst to atpakaļ, bet tas būs tikai vienu pavedienu socks, kas mums nav gluži tas, kas nepieciešams.
Tātad, mēs neatradām neko gatavu, tāpēc mums tomēr būs jāizdomā sava velosipēds. Mūsu velosipēda pamats būs atpakaļejošais socks uz golang, un klientu realizēsim uz PowerShell.
RSocksTun
Tātad, kādā veidā darbojas rsockstun?
RSocksTun pamats (turpmāk tekstā — rs) ir divi programmatūras komponenti — Yamux un Socks5 serveris. Socks5 serveris ir parasts lokālais socks5, tas tiek palaists uz klienta. Savienojumu multiplikācija uz to (vai atceraties par daudzthreads?) tiek nodrošināta ar yamux (). Šāda shēma ļauj palaist vairākus klienta socks5 serverus un izplatīt ārējās savienojumus uz tiem, pārsūtot tos caur vienu TCP savienojumu (gandrīz kā meterpreter) no klienta uz serveri, tādējādi īstenojot daudzplūsmu režīmu, bez kura mēs vienkārši nevarēsim pilnībā strādāt iekšējā tīklā.
Yamux darbības būtība ir tāda, ka tas ievieš papildu tīkla plūsmu līmeni, realizējot to kā 12 baitus lielu virsrakstu katram paketē. (Šeit mēs apzināti izmantojam vārdu «plūsma», nevis «plūst», lai nesajauktu lasītāju ar programmatisko plūsmu «thread» — šo jēdzienu mēs tāpat izmantosim šajā rakstā). Yamux virsrakstā ir iekļauts plūsmas numurs, karogi plūsmas uzstādīšanai/izbeigšanai, pārvedamo baitus skaits, pārsūtīšanas loga lielums.
Papildus plūsmas uzstādīšanai/izbeigšanai yamux ir realizēts keepalive mehānisms, kas ļauj uzraudzīt izveidotā sakaru kanāla atbilstību. Keepalive ziņojumu darbība tiek konfigurēta Yamux sesijas izveidē. Patiesībā no iestatījumiem tur ir tikai — divi parametri: enable/disable un paketu nosūtīšanas biežums sekundēs. Keepalive ziņojumus var nosūtīt gan yamux serveris, gan yamux klients. Saņemot keepalive ziņojumu, attālajai pusei jāatbild ar tieši tāda paša identitātes numura (faktiski — skaitļa) sūtīšanu, kuru tā saņēma. Kopumā, keepalive — tas pats ping, tikai yamux.
Detalizēta informācija par multiplexora darbību: paketes veidi, savienojumu uzstādīšanas un izbeigšanas karogi, datu pārsūtīšanas mehānisms ir aprakstīta k yamux.
Secinājums pirmajai daļai
Tātad, pirmajā raksta daļā mēs iepazināmies ar dažiem instrumentiem, kā organizēt atgriezeniskos tunelus, apskatījām to priekšrocības un trūkumus, izpētījām Yamux multiplexora darbības mehānismu un aprakstījām pamata prasības jaunizveidotajam PowerShell modulim. Nākamajā daļā mēs nodosimies paša moduļa izstrādei, faktiski, no nulles. Turpinājums sekos. Nepalaidiet garām 🙂
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish