Domeenifrontimine TLS 1.3 põhjal. Osa 2

Sissejuhatus

Esimese osa artikleid me andsime lühikese ülevaate encrypted SNI (eSNI) mehhanismist. Näitasime, kuidas selle alusel saab kõrvale hiilida kaasaegsetest DPI-süsteemidest (näiteks Beeline'i DPI ja keelatud RKN ruTracker), samuti uurisime uut domeeni esitlemise varianti selle mehhanismi põhjal.

Teises artikli osas keskendume praktilisematele aspektidele, mis on kasulikud RedTeam spetsialistidele nende raskes töös. Lõppude lõpuks on meie eesmärk mitte juurdepääs blokeeritud ressurssidele (selliste igapäevaste asjade jaoks on meil vana hea VPN). Õnneks on VPN-teenuse pakkujaid palju, nagu öeldakse, igale maitsele, värvile ja eelarvele.

Püüame rakendada domeeni esitlemise mehhanismi kaasaegsetes RedTeam tööriistades, nagu Cobalt Strike, Empire jne, ja anda neile täiendavaid võimalusi peegeldumiseks ja kaasaegsetest sisu filtrisüsteemidest kõrvale hiilimiseks.

Eelmine kord integreerisime eSNI mehhanismi OpenSSL raamatukokku ja kasutasime seda tuntud utiliidis curl. Kuid ühe curl'iga, nagu öeldakse, nälga ei jää. Loomulikult soovime midagi sarnast teostada kõrgema taseme keeltes. Kahjuks aga ei paku kiire otsing internetis meid suurt rahuldust, kuna eSNI mehhanismi tugi on täielikult rakendatud ainult GOLANGis. Nii et valik on meil üsna piiratud: kas kirjutame puhtas C või C++ kasutades muudetud OpenSSL raamatukogu või kasutame CloudFlare'i eraldi GOLANGi haru ja proovime oma tööriistu sinna portida. Siiski on veel üks variant, klassikalisem, kuid samas töömahukam – rakendada eSNI toetus Pythonis. Lõppude lõpuks kasutab Python samuti OpenSSL-i HTTPS-iga töötamiseks. Kuid selle variandi jätame kellegi teise arendamiseks, samas kui meie oleme rahul GOLANGis rakendusega, eriti kuna meie lemmik Cobalt Strike oskab suurepäraselt töötada väliste ühenduskanalitega (External C2 channel) – sellest räägime artikli lõpus.

Proovi rohkem…

Üks Go-s rakendatud tööriistu – meie areng sisesesse võrku pöördumiseks – tunnel rsockstun, mis btw, tuvastatakse nüüd Microsofti ja Symanteci lahenduste poolt väga kahjulikuna tarkvarana, mis on suunatud globaalsete probleemide loomisele...

Oleks tore kasutada ka eelmist arendust. Kuid siin tekib väike probleem. Asi on selles, et rsockstun algselt eeldab serveriga sünkroonse SSL-ühenduse kasutamist. See tähendab, et ühendus luuakse ühe korra ja püsib kogu tuunelija tööaja. Ja nagu arusaadav, http protokoll ei ole just selliseks töörežiimiks kohandatud – see töötab päring-vastus režiimis, kus iga uus http-päring toimub uue tcp-ühenduse raames.

Selle süsteemi peamine puudus on see, et server ei saa andmeid kliendile edastada, kuni klient ei saadeta uut http-päringut. Kuid õnneks on olemas palju variante selle probleemi lahendamiseks – andmete voogedastamiseks http protokolli kaudu (kui nii võib öelda, et me suudame vaadata oma lemmikseriaale ja kuulata muusikat portaalides, mis töötavad https-il, ja video ning audio edastamine on mitte midagi muud kui andmete voogedastus). Üks tehnoloogiatest, mis simuleerib täisfunktsionaalset tcp-ühendust http protokolli peal, on veebisoketitehnoloogia (WebSockets), mille peamine põhimõte on korraldada täisfunktsionaalne võrguühendus kliendi ja veebiserveri vahel.

Meie õnneks (hura-hura!!!) on see tehnoloogia vaikimisi sisse lülitatud kõigis CloudFlare’i hinnaplaanides ja töötab suurepäraselt koos eSNI-iga. Just seda me kasutame, et õpetada meie tuunelijat kasutama domeeni ümbersuunamist ja kaasaegsete DPI-de eest varjumist.

Veebisocketitest natuke

Esiteks räägime lihtsalt ja lühidalt veebisocketitest, et kõigil oleks aimu, millega me töötame.

Veebisocketite tehnoloogia võimaldab ajutiselt vahetada http-ühenduse standardse andmevoo edastamise vastu võrgusoketi kaudu, katkemata samal ajal olemasolevat tcp-ühendust. Kui klient soovib vahetada veebisoketile, saadab ta oma http-päringus mitmeid http-pealkirju. Kaks kohustuslikku pealkirja on Connection: Upgrade ja Upgrade: websocket. Samuti võib ta sundida veebisocketi protokolli versiooni (Sec-Websocket-Version: 13) ja midagi sarnast base64 veebisoka ID-d (Sec-WebSocket-Key: DAGDJSiREI3+KjDfwxm1FA==). Server vastab sellele HTTP-koodiga 101 Switching Protocols ja seadistab ka pealkirjad Connection, Upgrade ja Sec-WebSocket-Accept. Ülemineku protsess on visuaalselt demonstreeritud alloleval ekraanipildil:

Pärast seda võib WebSocketi ühenduse loomist pidada lõpetatuks. Kõik andmed, nii kliendilt kui serverilt, saadetakse nüüd mitte HTTP, vaid WebSocketi pealkirjadega (need algavad baitidega 0x82). Nüüd ei pea server enam ootama kliendi päringut andmete edastamiseks, kuna TCP-ühendus ei katkesta.

Golangis on veebisoka tööks mitmeid raamatukogusid. Neist kõige populaarsemad on Gorilla WebSocket ja standardne WebSocket. Kasutame viimasest, kuna see on lihtsam, väiksem ja nagu öeldakse, veidi kiirem.

Kliendi rsockstuni koodis peame asendama net.dial või tls.dial kutsed vastavate WebSocketi kutsudega:

Soovime, et meie tunneli kliendi osa oleks universaalne ja suudaks töötada nii otse SSL-ühenduse kui ka WebSocketi protokolli kaudu. Selleks loome eraldi funktsiooni func connectForWsSocks(address string, proxy string) error {…} analoogiliselt connectForSocks() ja kasutame seda veebisoketide tööks, juhul kui serveri aadress, mis on määratud kliendi käivitamisel, algab ws: või wss: (Secure WebSocketi puhul).

Tunneli serveripoolseks osaks loome samuti eraldi funktsiooni veebisoketide tööks. Seal luuakse HTTP klassi eksemplar ja määratakse HTTP-ühenduse töötleja (funktsioon wsHandler):

Ja terve ühenduse käsitlemise loogika (kliendi autoriseerimine parooli alusel, yamux sessiooni loomine ja lõpetamine) paigutame WebSocketi ühenduse töötlejasse:

Kompileerime projekti, käivitame serveripoolse osa:

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

Ja seejärel kliendipoolse osa:

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

Ja kontrollime tööd kohalikus hostis:

Jätkame domeeni edastamisega

WebSocketidega leiame end olevat sisenenud. Nüüd liikume otse eSNI ja domeeni edastamise juurde. Nagu juba eelnevalt mainitud, vajame DoH ja eSNI töötamiseks spetsiaalset golangi haru ettevõttelt CloudFlare. Me vajame haru, kus on eSNI tugi (pwu/esni).

Kloonime selle endale kohalikult või laadime ja puhastame vastava zip-faili:

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

Seejärel peame kopeerima GOROOT katalooge, asendama vastavad failid kloonitud harust ja seadma selle peamiseks. Et arendajaid sellest peavalust vabastada, on CloudFlare'i tiim valmistanud ette spetsiaalse skripti – _dev/go.sh. Lihtsalt käivitage see. Skript koos makefile'iga teevad kõik ise. Huvi pärast – võite sisse piiluda makefile'i, et näha detaile.

Pärast skripti töötamist, projekti kompileerimise ajal, peame GOROOT-ina määrama kohaliku katalooge, mille skript ette valmistas. Meie puhul näeb see välja nii:

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

Edasi peame rakendama tunneli funktsiooni, mis pärib ja parsib avalikke eSNI võtmeid soovitud domeeni jaoks. Meie puhul on need avalikud eSNI võtmed CloudFlare'i esiosa serveritest. Selleks 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 enda eest. Täitmise võtame failist esni_query.go, mis kuulub tls-tris'i koosseisu. Esimene funktsioon loob võrgu paketi CloudFlare'i DNS-serverile päringu tegemiseks, kasutades DoH (DNS-over-HTTPS) protokolli, teine – parsib päringu tulemused ja saab domeeni avalikku võtme väärtused, kolmas aga toimib konteinerina kahe esimese jaoks.

Seejärel lisame meie uude funktsiooni veebisoketi ühenduse: connectForWsSocks eSNI võtmete pärimise funktsionaalsuse domeeni jaoks. Kohas, kus serveri osa töötab, seadistame TLS parameetrid ja määrame vale "katte" domeeni nime:

Siinkohal tuleb märkida, et algselt ei olnud tls-tris haru mõeldud domeenifrondimise kasutamiseks. Seetõttu ei ole seal tähelepanu pööratud vale serveri nimele (client-hello paketi koostises edastatakse tühi serverName väli). Selle parandamiseks peame lisama TlsConfig struktuuri vastava vale serveri nime väli. Stdnt samm ServerName struktuuri ei saa kasutada, kuna seda kasutavad tls-i sisemised mehhanismid ja kui see erineb algsest, lõppeb tls-käepigistus veaga. Struktuuri TlsConfig kirjeldus on failis tls/common.go – seda peame me parandama:

Lisaks peame tegema muudatusi failis tls/handshake_client.go, et kasutada meie välja FakeServerName TLS-käeulatuse koostamiseks:

See on kõik! Projekti saab kompileerida ja töö kontrollida. Kuid enne kontrollimist tuleb seadistada CloudFlare'i konto. Noh, kuidas öelda, seadistada - lihtsalt loo konto CloudFlare'is ja seo oma domeen sellega. Kõik DoH, WebSocket ja ESNI funktsioonid on automaatselt CloudFlare'is lubatud. Pärast DNS-i rekordite uuendamist saab domeeni toimimist kontrollida, saates eSNI võtmete päringu:

dig +short txt _esni.df13tester.info 

Kui näete sarnast teavet oma domeeni puhul, siis tähendab see, et kõik töötab ja võib liikuda testimise juurde.

Käivitame Ubuntu VPS-i, näiteks DigitalOceanil. P.S. Meie puhul osutus just antud teenusepakkuja IP-aadress VPS-i osas RKN-i mustadesse nimekirjadesse. Seega ärge imestage, kui teil juhtub midagi sarnast. pidime kasutama VPN-i, et pääseda oma VPS-ile.

Kopeerime VPS-ile juba kompileeritud rsockstun'i (kui veel üks golangi pluss – saate oma projektid kompileerida ja käivitada mis tahes Linuxis, järgides ainult süsteemi arhitektuuri) ja käivitame serveri osa:

Siis käivitame kliendi osa:

Nagu näeme, ühendas klient CloudFlare'i frontend-serveri kaudu serveriga veebisoketi kasutades edukalt. Tunneli tõhususe kontrollimiseks saab teha curl-päringu läbi kohaliku socks5, mis on serveris avatud:

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

Esiteks pöördub tunneli loomise mehhanism DoH kaudu CloudFlare'i DNS-serveri poole sihtdomeeni eSNI võtmete saamiseks (paketid nr 1-19), seejärel pöördub frontend-serveri poole ja loob TLS-ühenduse, peites end samas domeeni taha www.google.com (see on vaikeväärtus, kui kliendi käivitamisel ei ole määratud vale domeeni). Oma vale domeeni määramiseks peate kasutama parameetrit -fronfDomain:

Nüüd on veel üks punkt. Vaikeväärtuste kohaselt on CloudFlare'i konto seadetes Flexibel SSL-režiim. See tähendab, et https-päringud CloudFlare'i frontend-serveritele klientidelt suunatakse meie serverisse mittekrüpteeritud (http) kujul. Just selle pärast käivitasime tunneliserveri mittesertifitseeritud režiimis (-listen ws:0.0.0.0), mitte (-listen wss:0.0.0.0).

Kuna täishäälestamise režiimi üleminekuks tuleb valida Täielik, või Full (strict) kui serveril on olemas kehtiv sertifikaat. Režiimi muutmisel suudame vastu võtta ühenduseid CloudFlare'iga https protokolli kaudu. Ärge unustage genereerida self-signed sertifikaati tunneli serveri osale.

Üks peeneid lugejaid küsib: „Aga kuidas on Windows klientidega? Kindlasti on peamine tunnelite kasutus tagakonnekti loomine ettevõtte arvutitega ja serveritega, kus on tavaliselt alati Windows. Kuidas ma pean tunneli kokkupanema Windowsi jaoks, veel spetsiifilise TLS-tekiga?“ Nüüd kujutame ette veel ühte funktsiooni, mis näitab, kui mugav on Go. Kompileerige Windowsi jaoks otse Kali's, 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"

See ongi kõik! Ja rohkem pole mingeid jamasid vaja. See tõesti töötab!

Kompilaatori lipud –w ja –s on vajalikud, et eemaldada liigsed killud täidesaatvast failist, vähendades selle suurust paar megabaiti. Lisaks saab seda hiljem UPX abil pakendada, et veelgi suurust vähendada.

Lõpetuseks

Artiklis näitasime golangis kirjutatud tunneli näitel uue domeeni fronting tehnoloogia rakendust, mis põhineb üsna huvitaval TLS 1.3 protokolli omadusel. Sarnasel viisil saab olemasolevat golangis kirjutatud tööriistakomplekti kohandada CloudFlare'i serverite kasutamiseks, näiteks Merlin — tuntud C2 või sundida CobaltStrike Beaconit kasutama eSNI domeeni frontingut, töötades Teamserveriga kaudu External C2 Channel, mis on rakendatud golangis, või standardses C++-s, kasutades patšitud versiooni OpenSSL-ist, millest rääkisime artikli eelmine osa. Ühesõnaga, fantaasiale ei ole piire.

Tunneli ja CloudFlare'i näide on esitatud kontseptsioonina ja hetkel on keeruline öelda, millised kaugemad perspektiivid sellisel domeeni frontingul on. Praegu on eSNI tugi rakendatud ainult CloudFlare'is ja teoreetiliselt ei takista miski neid seda frontingut välja lülitamast ja näiteks katkestamast tls-ühendusi, kui SNI ja eSNI ei kattu. Ühesõnaga, tulevik näitab. Kuid praegu tundub perspektiiv töötada "kremlin.ru varjus" üsna ahvatlev. Kas pole?

Uuendatud tunnelikoodi ja kompileeritud executables (exe-failid) on paigutatud projekti eraldi harusse github. Kõik tunneliga seotud probleemid on parem välja tuua projekti GitHubi lehe issue'ides.

Allikas: habr.com