Hyrje
Në pjesën e parë ne dhamë një përshkrim të shpejtë të mekanizmit të SNI të enkriptuar (eSNI). Treguam si mund të shmanget detektimi nga sistemet moderne DPI (në shembullin e DPI të Beeline dhe RTK-në e ndaluar të RuTracker), si dhe shqyrtuam një variant të ri të fronting të domainit në bazë të këtij mekanizmi.
Në pjesën e dytë të artikullit do të kalojmë në çështje më praktike që do të jenë të dobishme për specialistët e RedTeam në punën e tyre të vështirë. Pas gjithë kësaj, qëllimi ynë nuk është të fitojmë qasje në burime të bllokuara (për gjëra të tilla banale kemi VPN-in e vjetër dhe të mirë). Fatmirësisht, ekzistojnë shumë ofrues VPN, siç thuhet, për çdo shije, ngjyrë dhe buxhet.
Ne do të përpiqemi të aplikojmë mekanizmin e fronting të domainit për mjetet moderne të RedTeam, siç janë Cobalt Strike, Empire etj., dhe t'u japim atyre mundësi shtesë për mimikrim dhe shmangie nga sistemet moderne të filtrimit të përmbajtjes.
HerĂ«n e fundit, ne implementuam mekanizmin e eSNI nĂ« bibliotekĂ«n OpenSSL dhe e pĂ«rdorĂ«m me sukses nĂ« utilitarin e njohur curl. Por me njĂ« curl, siç thuhet, nuk do tĂ« ngopesh. Sigurisht, dĂ«shirojmĂ« tĂ« realizojmĂ« diçka tĂ« ngjashme nĂ« gjuhĂ« tĂ« nivelit tĂ« lartĂ«. Por, fatkeqĂ«sisht, kĂ«rkimi i shpejtĂ« nĂ« hapĂ«sirĂ«n e internetit na zhgĂ«njen, sepse mbĂ«shtetje pĂ«r mekanizmin e eSNI Ă«shtĂ« implementuar plotĂ«sisht vetĂ«m nĂ« GOLANG. kĂ«shtu qĂ« zgjedhja jonĂ« nuk Ă«shtĂ« shumĂ« e madhe: ose shkruajmĂ« nĂ« C ose C++ tĂ« pastĂ«r duke pĂ«rdorur bibliotekĂ«n e patçizuar OpenSSL, ose pĂ«rdorim njĂ« fork tĂ« veçantĂ« GOLANG nga CloudFlare dhe pĂ«rpiqemi tĂ« portojmĂ« mjetet tona atje. NĂ« parim, ka edhe njĂ« variant tjetĂ«r, mĂ« klasik, por njĂ«kohĂ«sisht edhe pune e madhe â Ă«shtĂ« tĂ« realizojmĂ« mbĂ«shtetje pĂ«r eSNI pĂ«r Python. NĂ« fund tĂ« fundit, Python gjithashtu pĂ«rdor OpenSSL pĂ«r tĂ« punuar me https. Por kĂ«tĂ« variant do ta lĂ«mĂ« pĂ«r zhvillim pĂ«r dikĂ« tjetĂ«r, ndĂ«rsa ne do tĂ« jemi tĂ« kĂ«naqur me realizimin nĂ« GOLANG, sidomos qĂ« Cobalt Strike ynĂ« i dashur e di tĂ« punojĂ« me kanale komunikimi tĂ« ndĂ«rtuara nga mjete tĂ« jashtme (External C2 channel) â pĂ«r kĂ«tĂ« do tĂ« flasim nĂ« fund tĂ« artikullit.
Try Harder...
NjĂ« nga mjetet e implementuara nĂ« Go â zhvillimi ynĂ« pĂ«r pivotimin brenda rrjetit â tunneluesi , i cili, pĂ«r tĂ« thĂ«nĂ« tĂ« vĂ«rtetĂ«n, tani detektohet nga mjete nga Microsoft dhe Symantec, si software shumĂ« tĂ« dĂ«mshĂ«m, tĂ« orientuar pĂ«r tĂ« prishur stabilitetin global...
Do tĂ« ishte mirĂ« tĂ« pĂ«rdorim zhvillimin e mĂ«parshĂ«m edhe nĂ« kĂ«tĂ« rast. Por kĂ«tu lind njĂ« problem i vogĂ«l. Problemi Ă«shtĂ« se fillimisht, rsockstun parashikon pĂ«rdorimin e njĂ« kanali SSL sinkron me serverin. Kjo do tĂ« thotĂ« se lidhja vendoset njĂ« herĂ« dhe ekziston gjatĂ« gjithĂ« kohĂ«s sĂ« punĂ«s sĂ« tunneluesit. Dhe, siç mund ta kuptoni, protokolli https nuk Ă«shtĂ« shumĂ« i destinuar pĂ«r njĂ« mod si ky â ai punon nĂ« modin kĂ«rkesĂ«-pĂ«rgjigje, ku çdo kĂ«rkesĂ« e re http ekziston nĂ« kuadĂ«r tĂ« njĂ« lidhjeje tĂ« re tcp.
MangĂ«sia kryesore e kĂ«tij skeme Ă«shtĂ« se serveri nuk mund t'i dĂ«rgojĂ« tĂ« dhĂ«na klientit derisa klienti tĂ« dĂ«rgojĂ« njĂ« kĂ«rkesĂ« tĂ« re http. Por, pĂ«r fat tĂ« mirĂ«, ekzistojnĂ« shumĂ« variante zgjidhjeje tĂ« kĂ«tij problemi â transmetimit tĂ« tĂ« dhĂ«nave nĂ«pĂ«rmjet protokollit http (nĂ« fund tĂ« fundit ne arrijmĂ« tĂ« shohim seritĂ« tona tĂ« preferuara dhe tĂ« dĂ«gjojmĂ« muzikĂ« nga portale qĂ« punojnĂ« nĂ« https, dhe transmetimi i videove dhe audios Ă«shtĂ« ashtusi si transmetimi i tĂ« dhĂ«nave). NjĂ« nga teknologjitĂ« pĂ«r imitim tĂ« punĂ«s sĂ« njĂ« lidhjeje tĂ« plotĂ« tcp mbi protokollin http Ă«shtĂ« teknologjia e web-sockets (WebSockets), ku qĂ«llimi kryesor Ă«shtĂ« organizimi i njĂ« lidhjeje tĂ« plotĂ« rrjetĂ«sore mes klientit dhe serverit web.
Për fatin tonë (ura-ura!!!), kjo teknologji është e përfshirë si standard në të gjitha planet e CloudFlare dhe punon mirë në kombinim me eSNI. Pikërisht atëherë do ta përdorim për të mësuar tunneluesin tonë të përdorë fronting të domainit dhe të fshihet nga sistemet moderne DPI.
Pak mbi WebSockets
Në radhë të parë, do të flasim pak dhe me fjalë të thjeshta rreth web-sockets, në mënyrë që të gjithë të kenë një ide të asaj me të cilën do të punojmë.
Teknologjia e web-sockets lejon që përkohësisht të kalojmë nga një lidhje http në transmetim standard të të dhënave nëpërmjet një socketi rrjetësor, pa e ndërprerë lidhjen tcp të vendosur. Kur klienti dëshiron të kalojë në web-socket, ai vendos disa headers http në kërkesën e tij http. Dy headers të domosdoshëm janë Connection: Upgrade dhe Upgrade: websocket. Ai gjithashtu mund të tregojë versionin e protokollit të web-socket (Sec-Websocket-Version: 13) dhe diçka të tillë si identifikuesi base64 të web-socketit (Sec-WebSocket-Key: DAGDJSiREI3+KjDfwxm1FA==). Serveri i përgjigjet me kodin http 101 Switching Protocols dhe gjithashtu vendos headers Connection, Upgrade dhe Sec-WebSocket-Accept. Procesi i kalimit është ilustruar më poshtë:
Pas kësaj, mund të themi se vendosja e lidhjes WebSocket është përfunduar. Të dhënat nga klienti dhe serveri tani do të dërgohen me tituj WebSocket (ata fillojnë me bajtin 0x82). Tani, serveri nuk ka nevojë të presë një kërkesë nga klienti për të përcjellë të dhëna, sepse lidhja tcp nuk ndërpritet.
Në Golang, ka disa biblioteka për punën me web-socket. Nga më të njohurit janë dhe standardja . Ne do të përdorim këtë të fundit, pasi është më e thjeshtë, më e vogël dhe funksionon, siç thonë, pak më shpejt.
Në kodin e klientit rsockstun ne duhet të zëvendësojmë thirrjet net.dial ose tls.dial me thirrjet përkatëse WebSocket:
Ne duam qĂ« pjesa klientore e tunelit tonĂ« tĂ« jetĂ« universale dhe e aftĂ« tĂ« punojĂ« si pĂ«rmes njĂ« lidhjeje tĂ« thjeshtĂ« ssl, ashtu edhe pĂ«rmes protokollit WebSocket. PĂ«r kĂ«tĂ«, ne do tĂ« krijojmĂ« njĂ« funksion tĂ« veçantĂ« func connectForWsSocks(address string, proxy string) error {âŠ} sipĂ«r connectForSocks() dhe do ta pĂ«rdorim atĂ« pĂ«r tĂ« punuar me web-socket nĂ« rast se adresa e serverit, e cila Ă«shtĂ« vendosur nĂ« fillim tĂ« klientit, fillon me ws: ose wss: (nĂ« rastin e Secure WebSocket).
Për pjesën serverore të tunelit, ne gjithashtu do të krijojmë një funksion të veçantë për punën me web-socket. Në të do të krijohet një instancë e klasës http dhe do të caktosh një trajtues për lidhjen http (funksioni wsHandler):
Dhe të gjithë logjikën e trajtimit të lidhjes (autorizimi i klientit me fjalëkalim, vendosja dhe përfundimi i sesionit yamux) do ta vendosim në trajtuesin e lidhjes WebSocket:
Kompilo projektin, ekzekuto pjesën serverore:
./rsockstun âlisten ws:127.0.0.1:8080 âpass P@ssw0rdDhe pastaj pjesĂ«n klientore:
./rsockstun -connect ws:127.0.0.1:8080 âpass P@ssw0rdDhe verifiko funksionimin nĂ« hostin lokal:
Le të kalojmë te domain-fronting
Me web-socket duket se kemi mbyllur. Tani le të kalojmë direkt te eSNI dhe domain-fronting. Siç u tha më parë, për të punuar me DoH dhe eSNI, duhet të marrim një degë speciale të Golang nga kompania . Na nevojitet dega me mbështetje për eSNI (pwu/esni).
E klonojmë atë në lokal ose e shkarkojmë dhe e shpaketojmë zip-in përkatës:
git clone -b pwu/esni https://github.com/cloudflare/tls-tris.gitPastaj na duhet tĂ« kopjojmĂ« katalogun GOROOT, tĂ« zĂ«vendĂ«sojmĂ« skedarĂ«t pĂ«rkatĂ«s nga dega e klonuar dhe ta vendosim si tĂ« parĂ«. PĂ«r tĂ« hequr kĂ«tĂ« ngarkesĂ« nga zhvilluesi, djemtĂ« nga CloudFlare pĂ«rgatitĂ«n njĂ« skenar tĂ« veçantĂ« â _dev/go.sh. Thjesht e ekzekutojmĂ« atĂ«. Skripti sĂ« bashku me makefile do tĂ« kryejnĂ« gjithçka vetĂ«. PĂ«r interes, mund tĂ« shikoni brenda makefile pĂ«r detaje.
Pas përfundimit të skenarit, gjatë kompilimit të projektit, na nevojitet të caktomë katalogun lokal të përgatitur nga skripti si GOROOT. Në rastin tonë kjo duket kështu:
GOROOT="/opt/tls-tris/_dev/GOROOT/linux_amd64" go build âŠ.MĂ« pas, na duhet tĂ« realizojmĂ« nĂ« tunel funksionalitetin e kĂ«rkesĂ«s dhe parsing tĂ« çelĂ«save publikĂ« eSNI pĂ«r domenin nĂ« fjalĂ«. NĂ« rastin tonĂ«, kĂ«to do tĂ« jenĂ« çelĂ«sat publikĂ« eSNI nga serverat e frontend-it tĂ« CloudFlare. PĂ«r kĂ«tĂ«, ne do tĂ« krijojmĂ« tre funksione:
func makeDoTQuery(dnsName string) ([]byte, error)
func parseTXTResponse(buf []byte, wantName string) (string, error)
func QueryESNIKeysForHost(hostname string) ([]byte, error)Emrat e funksioneve, nĂ« parim, flasin vetĂ«. Ne do tĂ« marrim mbushjen nga skedari esni_query.go, i cili bĂ«n pjesĂ« nĂ« tls-tris. Funksioni i parĂ« krijon njĂ« paketĂ« rrjeti me njĂ« kĂ«rkesĂ« pĂ«r serverin DNS tĂ« CloudFlare, duke pĂ«rdorur protokollin DoH (DNS-over-HTTPS), i dyti â analizojnĂ« rezultatet e kĂ«rkesĂ«s dhe marrin vlerat e çelĂ«save publikĂ« tĂ« domenit, ndĂ«rsa i treti Ă«shtĂ« njĂ« kontejner pĂ«r dy tĂ« parĂ«t.
Më pas, ne do të fusim në funksionin tonë të sapo krijuar për lidhjen me web-socket connectForWsSocks funksionalitetin e kërkesës eSNI për domenin. Atje ku funksionon pjesa serverore, vendosim parametrat TLS, si dhe caktosh emrin e 'domenit' të rremë:
KĂ«tu duhet tĂ« theksohet se fillimisht, dega tls-tris nuk Ă«shtĂ« e projektuar pĂ«r pĂ«rdorimin e domain-fronting. Prandaj, nĂ« tĂ« nuk i Ă«shtĂ« kushtuar vĂ«mendje emrit tĂ« rremĂ« tĂ« serverit (nĂ« paketĂ«n client-hello dĂ«rgohet njĂ« fushĂ« e zbrazĂ«t serverName). PĂ«r ta korigjuar kĂ«tĂ«, do tĂ« duhet tĂ« shtojmĂ« nĂ« strukturĂ«n TlsConfig fushĂ«n pĂ«rkatĂ«se FakeServerName. Ne nuk mund ta pĂ«rdorim fushĂ«n standarde ServerName tĂ« strukturĂ«s, pasi ajo pĂ«rdoret nga mekanizmat e brendshĂ«m tĂ« tls dhe nĂ«se do tĂ« ndryshojĂ« nga origjinali, atĂ«herĂ« tls-handshake do tĂ« pĂ«rfundojĂ« me njĂ« gabim. PĂ«rshkrimi i strukturĂ«s TlsConfig gjendet nĂ« skedarin tls/common.go â dhe ne do ta rregullojmĂ« atĂ«:
Përveç kësaj, do të duhet të bëjmë ndryshime në skedarin tls/handshake_client.go, për të përdorur fushën tonë FakeServerName gjatë formimit të TLS handshake:
Kjo është e gjitha! Mund të kompiloni projektin dhe të kontrolloni funksionimin. Por para se të filloni verifikimin, duhet të konfiguroni llogarinë CloudFlare. Si ta themi, thjesht krijoni një llogari në CloudFlare dhe lidheni domenin tuaj me të. Të gjitha veçoritë që lidhen me DoH, WebSocket dhe ESNI janë të aktivizuara në CloudFlare nga e drejta. Pas përditësimit të shënimeve DNS, mund të verifikoni funksionimin e domenit duke bërë një kërkesë për çelësat e eSNI:
dig +short txt _esni.df13tester.info 
Nëse shihni diçka të ngjashme për domenin tuaj, atëherë gjithçka funksionon siç duhet dhe mund të kaloni në testim.
Lansoni një Ubuntu VPS, për shembull, në DigitalOcean. P.S. Në rastin tonë, adresa IP e dhënë nga ofruesi doli në listat e zeza të RKN. Pra, mos u çudisni nëse ju ndodh diçka e ngjashme. Duhej të përdornim një VPN për të hyrë në VPS-në tonë.
KopjojmĂ« nĂ« VPS rsockstun e kompiliuar tashmĂ« (nĂ« fakt, kjo Ă«shtĂ« njĂ« prej pĂ«rparĂ«sive tĂ« golang â mund ta kompiloni projektin tuaj kĂ«tu dhe ta nisni nĂ« çdo Linux, duke respektuar vetĂ«m arkitekturĂ«n e sistemit) dhe nisni pjesĂ«n server:
Pastaj pjesa klient:
Siç mund ta shohim, klienti u lidh me sukses me serverin përmes serverit front-end të CloudFlare duke përdorur websockets. Për të kontrolluar nëse tuneli funksionon pikërisht si një tunel, mund të bëni një kërkesë curl përmes socks5 lokal, i hapur në server:
Tani do të shohim se çfarë sheh DPI në kanalin e komunikimit:
SĂ« pari, tuneluesi, duke pĂ«rdorur mekanizmin DoH, i drejtohet serverit DNS tĂ« Cloudflare pĂ«r çelĂ«sat e eSNI pĂ«r domenin e destinacionit (paketat â1-19), dhe mĂ« pas kontakton serverin front-end dhe krijon njĂ« lidhje TLS, duke u fshehur nĂ«n domenin (kjo Ă«shtĂ« vlera e paracaktuar, kur pĂ«rdoruesi nuk specifikon njĂ« domen tĂ« rremĂ« gjatĂ« nisjes sĂ« klientit). PĂ«r tĂ« specifikuar domenin tuaj tĂ« rremĂ«, duhet tĂ« pĂ«rdorni parametrin -fronfDomain:
Tani, akoma një çështje tjetër. Nga ana e paracaktuar, në cilësimet e llogarisë në CloudFlare është aktivizuar moda Flexible SSL. Kjo do të thotë se kërkesat https drejt serverëve front-end të Cloudflare nga klientët do të redirektohen në mënyrë të pa-enkriptuar (http) në serverin tonë. Pikërisht për këtë arsye ne filluam pjesën server të tuneluesit në modalitetin non-ssl (-listen ws:0.0.0.0), dhe jo (-listen wss:0.0.0.0).
Për të kaluar në modalitetin e plotë të enkriptimit, duhet të zgjidhni Full, ose Full (strict) nëse ka një certifikat të vërtetë në server. Pas kalimit të modalitetit, ne do të jemi në gjendje të pranojmë lidhje nga CloudFlare përmes protokollit https. Mos harroni të gjeneroni një certifikatë self-signed për pjesën server të tuneluesit.
Lexuesi i vëmendshëm do të pyesë: "Por si qëndron me klientin nën Windows? Me siguri, përdorimi kryesor i tuneluesit është për të ngritur një back-connect nga makinat dhe serverat korporativë, dhe aty për herë tjetër është gjithmonë Windows. Si mund ta kompiloj tuneluesin për Windows, duke përdorur edhe një stak specifik të TLS?" Tani do të paraqesim një tjetër funksionalitet që tregon se sa i përshtatshëm është golang. Kompiloni për Windows direkt nga Kali, thjesht duke shtuar parametrin GOOS=windows:
GOARCH=amd64 GOROOT="/opt/tls-tris/_dev/GOROOT/linux_amd64" GOOS=windows go build -ldflags="-s -w"Ose versionin 32-bit:
GOARCH=386 GOROOT="/opt/tls-tris/_dev/GOROOT/linux_amd64" GOOS=windows go build -ldflags="-s -w"Kjo është! Dhe më shumë asgjë tjetër nuk është e nevojshme. Kjo funksionon vërtet!
Flagat e kompilatorit -w dhe -s janë të nevojshme për të hequr rrethinat e tepërta nga skedari ekzekutiv, duke e bërë atë më të vogël me disa megabajt. Shtesë, mund të paketoni më pas duke përdorur UPX, për të zvogëluar më shumë madhësinë.
Në vend të përfundimit
NĂ« kĂ«tĂ« artikull, me shembullin e tuneluesit tĂ« shkruar nĂ« golang, kemi ilustruar aplikimin e teknologjisĂ« sĂ« re tĂ« fronting tĂ« domenit, e realizuar nĂ« njĂ« karakteristikĂ« mjaft interesante tĂ« protokollit TLS 1.3. NĂ« mĂ«nyrĂ« tĂ« ngjashme mund tĂ« adaptojmĂ« mjetet ekzistuese tĂ« shkruara nĂ« golang pĂ«r tĂ« punuar nĂ«pĂ«rmjet serverĂ«ve CloudFlare, pĂ«r shembull â C2 i njohur, ose tĂ« detyrojmĂ« CobaltStrike Beacon tĂ« pĂ«rdorĂ« fronting eSNI kur punon me Teamserver pĂ«rmes , implementuar nĂ« golang, ose nĂ« C++ standard me pĂ«rdorimin e versionit tĂ« patchuar tĂ« OpenSSL, pĂ«r tĂ« cilin ne folĂ«m nĂ« pjesĂ«n e kaluar tĂ« artikullit. NĂ« pĂ«rgjithĂ«si, fantazia nuk ka kufij.
Shembulli me tuneluesin dhe CloudFlare është paraqitur si një koncept dhe akoma është e vështirë të flasësh për perspektivat e largëta të këtij lloji të fronting të domenit. Në këtë moment, mbështetja e eSNI është e realizuar vetëm nga CloudFlare dhe, në parim, asgjë nuk u pengon atyre të çaktivizojnë këtë lloj të fronting dhe, për shembull, të ndërpresin lidhjet tls në rast të mos përputhjes SNI dhe eSNI. Në përgjithësi, e ardhmja do të tregojë. Por për momentin, perspektiva e punës nën "mbulesën kremlin.ru" duket mjaft tërheqëse. A nuk është kështu?
Kodi i azhurnuar i tuneluesit, si dhe skedarët ekzekutivë të kompiliuar janë të vendosur në një degë të veçantë të projektit në . Për çdo problem të mundshëm me tuneluesin, është më mirë të shkruani issue në faqen e projektit në GitHub.
Burimi: habr.com
