TLS 1.3 baasil põhinev domeeni esitlemine. Osa 2

Sissejuhatus

Esimese osa jooksul artikkel andisime ülevaate encrypted SNI (eSNI) mehhanismist. Näitasime, kuidas selle põhjal on võimalik vältida tänapäevaste DPI-süsteemide tuvastamist (näiteks Beeline'i DPI ja keelatud RKN ruTracker), samuti uurisime uut domeeni silumist selle mehhanismi põhjal.

Teise osa jooksul liikudes keskendume praktilisematele külgedele, mis on kasulikud RedTeam spetsialistidele nende raske töö juures. Lõppkokkuvõttes on meie eesmärk mitte ligipääs blokeeritud ressurssidele (selle jaoks on meil alati olemas vana hea VPN). Hea on, et VPN-teenuse pakkujaid on tohutult, nagu öeldakse, igaks maitseks, värviks ja eelarveks.

Püüame rakendada domeeni silumise mehhanismi tänapäevaste RedTeam tööriistadega, näiteks Cobalt Strike'i, Empire'i jne, ja anda neile täiendavaid võimalusi varjatuks jäämiseks ja tänapäevaste sisu filtreerimise süsteemide vältimiseks.

Eelmisel korral integreerisime eSNI mehhanismi OpenSSL raamatukogusse ja kasutasime seda tuttavas utiliidis curl. Kuid ühe curl'iga, nagu öeldakse, nälga ei jää. Loomulikult tahaksime sarnast lahendust ka kõrgema taseme keeltes. Kahjuks, kiire otsing internetis pettis meid, kuna eSNI mehhanismi täieõiguslik tugi on teostatud ainult GOLANGis. Seega ei ole meie valik eriti lai: kas kirjutame puhtas C's või C++-s muudetud OpenSSL raamatukoguga või kasutame CloudFlare'i eraldiseisvat GOLANGi forki ja proovime oma tööriistu sinna portida. Tegelikult on veel üks variant, klassikalisem, kuid samas töömahukas – rakendada eSNI tuge Pythonis. Lõppude lõpuks kasutab Python samuti OpenSSL-i https-iga töötamiseks. Kuid selle variandi jätame kellegi teise arendamiseks ja me jääme rahule GOLANGi lahendusega, eriti kuna meie lemmik Cobalt Strike oskab suurepäraselt töötada kolmandate osapoolte vahenditega üles ehitatud sidekanaliga (External C2 channel) – sellest räägime artikli lõpus.

Proovige rohkem…

Üks meie Go keeles teostatud tööriistu – meie arendus sisemistele tunneli ühendustele – tunneli lahendus rsockstun, mis, muide, tuvastatakse täna Microsofti ja Symanteci tööriistadega väga kahjuliku tarkvarana, mille eesmärk on globaalse stabiliteedi häirimine …

Oleks tore kasutada eelnevat arendust ka antud juhul. Kuid siin tekib väike probleem. Asi on selles, et algselt eeldab rsockstun serveriga suhtlemiseks sünkroneeritud SSL-kanali kasutamist. See tähendab, et ühendus luuakse ainult üks kord ja see püsib tunneli töötamise ajal. Nagu aru saate, ei ole http protokoll selliseks töörežiimiks just kõige sobivam – see töötab päringu-vastuse režiimis, kus iga uus http-päring eksisteerib uue tcp-ühenduse raames.

Peamine puudus sellises skeemis on see, et server ei saa andmeid kliendile edastada seni, kuni klient ei saada uut HTTP-päringut. Õnneks on selle probleemi lahendamiseks palju võimalusi – andmete voogedastus HTTP-protokollis (lõppude lõpuks suudame ikkagi vaadata oma lemmiksarju ja kuulata muusikat HTTPS-platvormidelt, ja video ning audio edastamine on mitte midagi muud kui andmete voogedastus). Üks tehnoloogia täieõigusliku TCP-ühenduse emuleerimise jaoks HTTP-protokolli peal on veebisoketid (WebSockets), mille põhijõud seisneb täieõigusliku võrguühenduse korraldamises kliendi ja veebiserveri vahel.

Meie õnneks (hüüdke rõõmust!!!) on see tehnoloogia vaikimisi kõikides CloudFlare'i hinnaklassides sisse lülitatud ja töötab hästi eSNI-ga. Just seda me kasutame, et õpetada meie tunnelit kasutama domeeni esitlemist ja varjama end kaasaegsete DPI-de eest.

Veebisoketidest natuke

Esiteks räägime lühidalt ja lihtsate sõnadega veebisocketitest, et kõik saaksid aimu, millega me tegeleme.

Veebipoodide tehnoloogia võimaldab ajutiselt vahetada http-ühendust tavapärase andmevoo edastamise vahel võrgu soketi kaudu, katkestamata samal ajal kehtivat tcp-ühendust. Kui klient soovib vahetada veebipoodi, saadab ta oma http-päringus mitmeid http-pealkirju. Kaks kohustuslikku pealkirja on Connection: Upgrade ja Upgrade: websocket. Samuti saab ta sundida veebipoodide protokolli versiooni (Sec-WebSocket-Version: 13) ja midagi nagu base64 identifikaator veebipoodi (Sec-WebSocket-Key: DAGDJSiREI3+KjDfwxm1FA==). Server vastab http-koodiga 101 Switching Protocols ja seadistab samuti pealkirjad Connection, Upgrade ja Sec-WebSocket-Accept. Protsessi vahetus on selgelt näidatud alloleval ekraanipildil:

Pärast seda võib veebipoodide ühenduse loomist pidada lõpetatuks. Kõik andmed nii kliendilt kui serverilt varustatakse nüüd mitte http, vaid WebSocket pealkirjadega (need algavad baitiga 0x82). Nüüd ei pea server ootama kliendi päringut andmete edastamiseks, kuna tcp-ühendus ei purune.

Go keeles veebipoodide käsitlemiseks on mitmeid raamatukogusid. Populaarseimate hulka kuuluvad Gorilla WebSocket ja standardne WebSocket. Kasutame viimasena, kuna see on lihtsam, kompaktsem ja peab olema veidi kiirem.

Kliendikoodis rsockstun peame asendama net.dial või tls.dial vastavate WebSocketi kõnedega:

Soovime muuta meie tunnelikliendi osa universaalseks, et see töötaks nii otse sslühenduse kui ka WebSockset protokolli kaudu. Selleks loome eraldi funktsiooni. func connectForWsSocks(address string, proxy string) error {…} sarnasel põhjusel connectForSocks() ja kasutame seda WebSocketide jaoks juhul, kui serveri aadress, mis on määratud kliendi käivitamisel, algab ws: või wss: (Secure WebSocketi puhul).

Tunneliserveri poole jaoks loome samuti WebSocketide jaoks eraldi funktsiooni. Seal luuakse http klassi eksemplar ja määratakse httpühenduse handler (funktsioon wsHandler):

Kogu ühenduse töötlemise loogika (kliendi autoriseerimine parooli järgi, yamux sessiooni loomine ja lõpetamine) paigutatakse WebSocketi ühenduse handlerisse:

Kompileerime projekti, käivitame serveri poole:

./rsockstun –listen ws:127.0.0.1:8080 –pass P@ssw0rd

Ja seejärel kliendi osa:

./rsockstun -connect ws:127.0.0.1:8080 –pass P@ssw0rd

Ja kontrollime tööd kohalikul hostil:

Liigutame edasi domeeni esiplaanile

Tundub, et me oleme veebiküsimustega juba hakkama saanud. Nüüd liigume otse eSNI ja domeeni esiplaanile. Nagu varem mainitud, vajame töötamiseks DoH ja eSNI jaoks spetsiaalset Golangi haru ettevõttelt CloudFlare. Me vajame haru, mis toetab eSNI (pwu/esni).

Kloonime selle endale kohalikult või laadime alla ja väljastame sobiva zipi:

git clone -b pwu/esni https://github.com/cloudflare/tls-tris.git

Seejärel peame kopeerima GOROOT katalooge, asendama kloonitud harust vastavad failid ja seadistama selle põhikataloogiks. Arendajate peavalude vähendamiseks on CloudFlare'i meeskond valmistanud spetsiaalse skripti – _dev/go.sh. Lihtsalt käivitage see. Skript koos makefile'iga teeb kõik ise. Huvi korral — võite teha pilgu makefile'i detailide jaoks.

Pärast skripti töötamist, projekti kompileerimisel, peame määrama GOROOT-ina skripti ettevalmistatud kohalikku katalooge. Meie puhul näeb see välja järgmine:

GOROOT="/opt/tls-tris/_dev/GOROOT/linux_amd64" go build ….

Seejärel peame tunnelis rakendama funktsionaalsuse eSNI võtmete pärimiseks ja analüüsimiseks soovitud domeenile. Meie puhul on need CloudFlare'i esiplaaniserverite avalikud eSNI võtmed. Selle saavutamiseks loome kolm funktsiooni:

func makeDoTQuery(dnsName string) ([]byte, error)
func parseTXTResponse(buf []byte, wantName string) (string, error)
func QueryESNIKeysForHost(hostname string) ([]byte, error)

Funktsioonide nimed räägivad põhimõtteliselt enda eest. Sisu võime võtta failist esni_query.go, mis kuulub tls-tris'i koosseisu. Esimene funktsioon loob võrgu paketi päringuks CloudFlare'i DNS-serverile kasutades protokolli DoH (DNS-over-HTTPS), teine - analüüsib päringu tulemusi ja saab domeeni avalikud võtme väärtused, kolmas on konteiner esimestele kahele.

Seejärel toome meie, äsja loodud, veebisoketi ühenduse funktsiooni connectForWsSocks eSNI võtmete pärimise funktsionaalsuse domeeni jaoks. Seal, kus serveripool töötab, seadistame TLS parameetrid ja määrame vale «maskendatud domeeni» nime:

Siin on oluline märkida, et algselt ei olnud tls-tris haru mõeldud domeeni esitlemise jaoks. Seetõttu ei pöörata tähelepanu vale serveri nimele (client-hello paketi raames edastatakse tühi serverName väli). Selle parandamiseks peame lisama TlsConfig struktuuri vastava vale serveri nime välja. Me ei saa kasutada struktuuri standardset ServerName välja, kuna seda kasutavad sisemised tls mehhanismid ja kui see erineb algsest, siis lõppeb tls-käepigistus veaga. TlsConfig struktuuri kirjeldus on failis tls/common.go – seda peamegi parandama:

Lisaks peame tegema muudatusi failis tls/handshake_client.go, et kasutada meie vale serveri nime välja TLS käepigistuse vormimisel:

Selleks on kõik! Projekti saab kompileerida ja tööle testida. Kuid enne kontrollimise käivitamist tuleb seadistada CloudFlare'i konto. Kuidas seda öelda, seadistada – lihtsalt luua CloudFlare'is konto ja siduda oma domeen sellega. Kõik DoH, WebSocket ja ESNI seonduvad funktsioonid on CloudFlare'is vaikimisi lubatud. Pärast DNS-kirjete värskendamist on võimalik domeeni tööd kontrollida, saates eSNI võtmete päringu:

dig +short txt _esni.df13tester.info 

Kui teie domeeni jaoks ilmub midagi sarnast – siis kõik töötab ja saate jätkata testimisega.

Käivitame Ubuntu VPS, näiteks DigitalOceanis. P.S. Meie puhul osutus lihtsalt välja antud VPS-i IP-aadress RKNi mustadesse nimekirjadele kuuluvaks. Seega ärge üllatuge, kui juhtub midagi sarnast. Pidi kasutama VPN-i, et oma VPS-ile juurde pääseda.

Kopeerime VPS-ile juba kompileeritud rsockstun (see on muide veel üks Go-eeliste hulk – võite projekti enda juures kompileerida ja käivitada igal Linuxil, järgides ainult süsteemi arhitektuuri) ja käivitame serveri osa:

Seejärel käivitame kliendi osa:

Kuidas me näeme, on klient edukalt ühendatud serveriga CloudFlare'i eesserveri kaudu veebisoketi kasutamisega. Tunneli korrektse toimimise kontrollimiseks saab teha cURL-päringu kohaliku SOCKS5 kaudu, mis on serveris avatud:

Nüüd vaatame, mida DPI näeb sidekanalis:

Esialgu pöördub tunneliteenuse osutaja DoH mehhanismi kaudu CloudFlare'i DNS-serveri poole, et saada eSNI-võtmed sihtdomeeni jaoks (paketid nr 1-19), ja seejärel pöördub eesserveri poole ning loob TLS-ühenduse, varjates end samas domeeni taha. www.google.com (see on vaikimisi väärtus, kui kliendi käivitamisel pole vale domeeni määratud). Oma vale domeeni määramiseks tuleb kasutada parameetrit -fronfDomain:

Nüüd veel üks punkt. Vaikimisi on CloudFlare'i konto seadetes seadistatud Flexible SSL töörežiim. See tähendab, et HTTPS-päringud CloudFlare'i eesserveritele klientidelt suunatakse meie serverisse krüpteerimata (HTTP) kujul. Just seetõttu käivitasime tunneldaja serveri osa non-ssl režiimis (-listen ws:0.0.0.0), mitte (-listen wss:0.0.0.0).

Täieliku krüpteerimise režiimi ülemineku jaoks tuleb valida Täielik, või Täielik (range) olemasoleva sertifikaadi olemasolu korral serveris. Režiimi vahetamise järel saame vastu võtta ühendusi CloudFlare'ilt https protokolli kaudu. Ära unusta genereerida iseallkirjastatud sertifikaati tunneliteenuse serveripoolseks osaks.

Küsimus, mis võiks huvi pakkuda: "Kuidas on lood Windowsi kliendiga? Tõenäoliselt on tunneliteenuse peamine kasutusala tagasijõudmine ettevõtte masinatelt ja serveritelt, kus tavaliselt on alati Windows. Kuidas ma saan tunnelit Windowsi jaoks kompileerida, ja veel spetsiifilise TLS-i virna kasutades?" Nüüd tutvustame veel ühte funktsiooni, mis näitab, kui mugav Go on. Kompileerime Windowsi jaoks otse Kali-st, lisades lihtsalt parameetri GOOS=windows:

GOARCH=amd64 GOROOT="/opt/tls-tris/_dev/GOROOT/linux_amd64" GOOS=windows go build -ldflags="-s -w"

Või 32-bitine variant:

GOARCH=386 GOROOT="/opt/tls-tris/_dev/GOROOT/linux_amd64" GOOS=windows go build -ldflags="-s -w"

Kõik! Ja rohkem muretseda ei ole vaja. See tõesti töötab!

Kompilaatori lipud –w ja –s on vajalikud selleks, et eemaldada täiendav prügi täidetavast failist, muutes selle paar megabaiti väiksemaks. Lisaks saab selle hiljem pakendada UPX-i abil, et veelgi vähendada faili suurust.

Kokkuvõtte asemel

Artiklis näitasime, kasutades golangis kirjutatud tunnelit, uue domeenifrontimise tehnoloogia rakendamist, mis põhineb üsna huvitaval TLS 1.3 protokolli omadusel. Samamoodi saab olemasolevat golangis kirjutatud tööriista kohandada töötama CloudFlare'i serverite kaudu, näiteks. Merlin — tuntud C2 või sundida CobaltStrike Beaconit kasutama eSNI domeenifrontimist Teamserveriga suhtlemisel. External C2 Channel, mis on rakendatud golangis või standardses C++-s kasutades propatchitud versiooni OpenSSL-ist, millest rääkisime artikli eelmisel osal. Ühesõnaga, fantaasia on piiramatu.

Tunnelija ja CloudFlare'i näide on esitatud kontseptsioonina ja praegu on keeruline rääkida sellise domeenifrontimise kaugematest perspektiividest. Praegu on eSNI tugi rakendatud ainult CloudFlare'is ja teoreetiliselt ei takista miski neil taolist frontimist välja lülitada ja näiteks katkestada TLS-ühendusi, kui SNI ja eSNI ei ühti. Ühesõnaga, tulevik näitab. Kuid praegu tundub perspektiiv töötada "kremlin.ru" varjus üsna ahvatlev. Kas pole?

Uuendatud tunneli kood ja kompileeritud täitev exe-failid on paigutatud projekti eraldi haru alla github. Kõigi tunneli võimalike probleemide kohta on parem kirjutada probleemid projektilehe GitHubis.

Allikas: habr.com