Domänfrontering baserat på TLS 1.3. Del 2

Inledning

I den första delen Artikel Vi har gett en kort beskrivning av den krypterade SNI-mekanismen (eSNI). De visade hur det kan användas för att undvika upptäckt av moderna DPI-system (med hjälp av exemplet Beelines DPI och rutrackern som förbjudits av RKN), och undersökte även en ny version av domänfronting baserad på denna mekanism.

I den andra delen av artikeln går vi vidare till mer praktiska saker som kommer att vara användbara för RedTeam-specialister i deras svåra arbete. Vårt mål är trots allt inte att få tillgång till blockerade resurser (för sådana triviala saker har vi en gammaldags VPN). Lyckligtvis finns det, som man brukar säga, många VPN-leverantörer för varje smak, färg och budget.

Vi kommer att försöka tillämpa domänfronteringsmekanismen på moderna RedTeam-verktyg, såsom Cobalt Strike, Empire, etc., och ge dem ytterligare funktioner för mimik och kringgående av moderna innehållsfiltreringssystem.

Förra gången implementerade vi eSNI-mekanismen i OpenSSL-biblioteket och använde den framgångsrikt i det välbekanta curl-verktyget. Men, som man säger, man kan inte leva bara på kurla. Självklart skulle jag vilja implementera något liknande i högnivåspråk. Men tyvärr gör en snabb sökning genom nätverkets vidsträckta nätverk oss besvikna, eftersom stöd för eSNI-mekanismen endast är fullt implementerat i GOLANG. Så vi har inte mycket att välja mellan: antingen skriver vi i ren C eller C++ med hjälp av det uppdaterade OpenSSL-biblioteket, eller så använder vi en separat förgrening av GOLANG från CloudFlare och försöker porta vår verktygslåda dit. I princip finns det ett annat alternativ, mer klassiskt, men samtidigt arbetskrävande – det är att implementera eSNI-stöd för Python. Python använder ju trots allt även OpenSSL för att hantera https. Men vi lämnar det här alternativet åt någon annan att utveckla, och vi själva kommer att vara nöjda med implementeringen på Golang, särskilt eftersom vår älskade Cobalt Strike är fullt kapabel att arbeta med en kommunikationskanal byggd av tredjepartsmedel (Extern C2-kanal) - vi kommer att prata om detta i slutet av artikeln.

Försök hårdare…

Ett av verktygen som implementerats i Go är vår utveckling för att koppla in sig i nätverket - tunneler rsockstun, som för övrigt nu upptäcks av Microsoft och Symantec som mycket skadlig programvara som syftar till att störa den globala stabiliteten...

Det vore bra att använda den tidigare utvecklingen även i detta fall. Men här uppstår ett litet problem. Poängen är att rsockstun initialt innebär användning av en synkron SSL-kommunikationskanal med servern. Det innebär att förbindelsen upprättas en gång och existerar under hela tunneldriften. Och, som du förstår, är https-protokollet egentligen inte utformat för detta driftsätt – det fungerar i request-response-läge, där varje ny http-förfrågan finns inom en ny tcp-anslutning.

Den största nackdelen med detta schema är att servern inte kan överföra data till klienten förrän klienten skickar en ny http-förfrågan. Men som tur är finns det många alternativ för att lösa detta problem - strömmande data via http-protokollet (vi lyckas ju trots allt på något sätt titta på våra favorit-TV-serier och lyssna på musik från portaler som fungerar på https, och överföringen av video och ljud är inget annat än strömmande data). En av teknikerna för att emulera driften av en fullfjädrad TCP-anslutning över HTTP-protokollet är WebSockets-tekniken, vars huvudsakliga essens är att organisera en fullfjädrad nätverksanslutning mellan klienten och webbservern.

Som tur är för oss (hurra hurra!!!) ingår den här tekniken som standard i alla CloudFlare-planer och fungerar utmärkt i kombination med eSNI. Det här är precis vad vi kommer att använda för att lära vår tunnelerare att använda domänfronting och dölja sig från modern DPI.

Lite om WebSockets

Först och främst kommer vi kortfattat och enkelt att förklara web sockets så att alla har en uppfattning om vad vi kommer att arbeta med.

Web Socket-tekniken låter dig tillfälligt växla från en http-anslutning till en vanlig strömmande dataöverföring via ett nätverksuttag utan att bryta den etablerade TCP-anslutningen. När en klient vill byta till en webbsocket anger den flera http-rubriker i sin http-begäran. Två obligatoriska rubriker är – Anslutning: Uppgradering и Uppgradering: websocket. Den kan också tvångsmässigt ange websocket-protokollversionen (Sec-Websocket-version: 13) och något liknande base64 websocket-identifierare (Sec-WebSocket-nyckel: DAGDJSiREI3+KjDfwxm1FA==). Servern svarar med http-koden 101 Switching Protocols och ställer även in headern. Anslutning, Uppgradering и Sec-WebSocket-Acceptera. Växlingsprocessen visas tydligt på skärmbilden nedan:

Efter detta kan installationen av WebSocket-anslutningen anses vara klar. All data från både klienten och servern kommer nu att levereras med WebSocket-rubriker istället för http (de börjar med byte 0x82). Nu behöver servern inte vänta på en begäran från klienten för att överföra data, eftersom tcp-anslutningen inte är bruten.

Golang har flera bibliotek för att arbeta med webbsockets. De mest populära av dem är Gorilla WebSocket och standard WebSocket. Vi kommer att använda det senare, eftersom det är enklare, mindre och fungerar, som man säger, lite snabbare.

I rsockstun-klientkoden måste vi ersätta net.dial- eller tls.dial-anropen med motsvarande WebSocket-anrop:

Vi vill göra klientdelen av vår tunnel universell och kapabel att fungera både via en direkt SSL-anslutning och via WebSockset-protokollet. För detta skapar vi en separat funktion func connectForWsSocks(adresssträng, proxysträng) fel {…} i analogi med anslutFörStrumpor() och vi kommer att använda den för att arbeta med web sockets om serveradressen som anges när klienten startas börjar med ws: eller wss: (i fallet med Secure WebSocket).

För serverdelen av tunneln kommer vi också att skapa en separat funktion för att arbeta med web sockets. Den skapar en instans av http-klassen och ställer in http-anslutningshanteraren (wsHandler-funktionen):

Och vi kommer att placera all logik för att bearbeta anslutningen (klientautentisering med lösenord, installation och avslutning av yamux-sessionen) i WebSocket-anslutningshanteraren:

Vi kompilerar projektet och startar serverdelen:

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

Och sedan klientdelen:

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

Och vi kontrollerar arbetet på den lokala värden:

Gå vidare till domänfronting

Vi verkar ha listat ut webbsockets. Nu går vi vidare till eSNI och domänfronting. Som tidigare nämnts, för att arbeta med DoH och eSNI behöver vi ta en särskild gren av Golang från företaget. CloudFlare. Vi behöver en filial med eSNI-stöd (pwu/esni).

Vi klonar den lokalt eller laddar ner och packar upp motsvarande zip-fil:

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

Sedan måste vi kopiera GOROOT-katalogen, ersätta motsvarande filer från den klonade grenen och ställa in den som huvudkatalogen. För att bespara utvecklaren detta besvär har killarna från CloudFlare förberett ett speciellt skript – _dev/go.sh. Vi bara lanserar det. Skriptet tillsammans med makefilen kommer att göra allt själva. Av intresse kan du titta inuti makefilen för detaljer.

Efter att ha kört skriptet, när vi kompilerar projektet, måste vi ange den lokala katalogen som förberedts av skriptet som GOROOT. I vårt fall ser det ut så här:

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

Därefter behöver vi implementera funktionen för att begära och analysera offentliga eSNI-nycklar för den önskade domänen i tunneln. I vårt fall kommer dessa att vara de kryptografiska eSNI-nycklarna från CloudFlares frontend-servrar. För att göra detta kommer vi att skapa tre funktioner:

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

Funktionernas namn talar i princip för sig själva. Vi tar innehållet från filen esni_query.go, som är en del av tls-tris. Den första funktionen skapar ett nätverkspaket med en begäran till CloudFlare DNS-servern med hjälp av DoH-protokollet (DNS-over-HTTPS), den andra analyserar frågeresultaten och hämtar värdena för domänens publika nycklar, och den tredje är en behållare för de två första.

Därefter lägger vi till funktionen web socket connection till vår nyskapade funktion. connectForWsSocks funktionalitet för att begära eSNI-nycklar för en domän. Där serverdelen fungerar ställer vi in ​​TLS-parametrarna och anger även namnet på den falska "täckdomänen":

Det bör noteras här att tls-tris-grenen initialt inte var utformad för användning av domänfronting. Därför uppmärksammar den inte det falska servernamnet (ett tomt serverName-fält överförs i client-hello-paketet). För att åtgärda detta måste vi lägga till motsvarande FakeServerName-fält i TlsConfig-strukturen. Vi kan inte använda standardfältet ServerName i strukturen eftersom det används av interna tls-mekanismer och om det skiljer sig från originalet kommer tls-handskakningen att avslutas med ett fel. Beskrivningen av TlsConfig-strukturen finns i filen tls/common.go – det här är vad vi behöver korrigera:

Dessutom måste vi göra ändringar i filen tls/handshake_client.go, för att använda vårt FakeServerName-fält när man skapar en TLS-handskakning:

Det är allt! Du kan sammanställa projektet och kontrollera arbetet. Men innan du kör kontrollen måste du skapa ett CloudFlare-konto. Tja, hur kan jag säga att jag ska ställa in det? Skapa bara ett konto på Cloudflare och länka din domän till det. Alla DoH-, WebSocket- och ESNI-relaterade funktioner är aktiverade i CloudFlare som standard. När DNS-posterna har uppdaterats kan du kontrollera domänens funktion genom att begära eSNI-nycklar:

dig +short txt _esni.df13tester.info 

Om du ser något liknande för din domän, fungerar allt för dig och du kan gå vidare till testning.

Vi lanserar Ubuntu En VPS, till exempel, på DigitalOcean. PS: I vårt fall hamnade VPS-IP-adressen vi just fått från vår leverantör på Roskomnadzors svarta lista. Så bli inte förvånad om något liknande händer dig. Jag var tvungen att använda en VPN för att komma åt min VPS.

Vi kopierar den redan kompilerade rsockstun till VPS:en (förresten, detta är ytterligare en skönhet med Golang - du kan kompilera projektet själv och köra det på vilken Linux som helst, bara med tanke på systemets bitvärde) och startar serverdelen:

Och sedan klientdelen:

Som vi kan se har klienten framgångsrikt anslutit till servern via CloudFlares frontend-server med hjälp av en webbsocket. För att kontrollera att tunneln fungerar exakt som en tunnel kan du göra en curl-förfrågan via lokala socks5 som är öppnade på servern:

Nu ska vi se vad DPI ser i kommunikationskanalen:

Först kontaktar tunneleraren, med hjälp av DoH-mekanismen, Cloudflares DNS-server för eSNI-nycklar för destinationsdomänen (paket #1-19), och kontaktar sedan frontend-servern och upprättar en TLS-anslutning, gömd bakom domänen. www.google.com (Detta är standardvärdet när ingen falsk domän anges när klienten startas). För att ange din falska domän måste du använda parametern -fronfDomain:

Nu en sak till. Som standard är dina CloudFalre-kontoinställningar inställda på Flexibelt SSL-läge. Det här innebär att https-förfrågningar till Cloudflares frontend-servrar från klienter kommer att vidarebefordras i okrypterad (http) form till vår server. Det är därför vi lanserade serverdelen av tunneln i icke-SSL-läge ( -listen ws:0.0.0.0), och inte ( -listen wss:0.0.0.0).

För att växla till fullständigt krypteringsläge måste du välja full, eller Fullständig (strikt) om det finns ett riktigt certifikat på servern. Efter att ha bytt läge kommer vi att kunna acceptera anslutningar från CloudFlare via https-protokollet. Glöm inte att generera ett självsignerat certifikat för serversidan av tunneln.

Den nyfikne läsaren kommer att fråga: ”Hur är det med klienten under Windows"Trots allt är den huvudsakliga användningen av en tunneler förmodligen att upprätta en backend-anslutning från företagsmaskiner och servrar, och det är vanligtvis alltid Windows. Hur kompilerar jag en tunneler för Windows, särskilt med en specifik TLS-stack?" Nu ska vi introducera ytterligare en funktion som visar hur bekvämt Golang är. Vi kompilerar för Windows direkt från Kali genom att helt enkelt lägga till parametern GOOS=windows:

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

Eller 32-bitarsversionen:

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

Alla! Och inget mer krångel behövs. Det här fungerar verkligen!

Kompilatorflaggorna -w och -s behövs för att ta bort onödigt skräp från den körbara filen, vilket gör den ett par megabyte mindre. Dessutom kan den sedan paketeras med UPX för att ytterligare minska storleken.

I stället för en slutsats

I den här artikeln, med hjälp av exemplet med en tunnelerare skriven i Golang, demonstrerade vi tydligt användningen av en ny domänfronteringsteknik, implementerad på en ganska intressant funktion i TLS 1.3-protokollet. På liknande sätt kan du anpassa befintliga verktyg skrivna i Golang för att fungera via CloudFlare-servrar, till exempel. Merlin — känd C2, eller tvinga CobaltStrike Beacon att använda eSNI-domänfronting när man arbetar med Teamserver via Extern C2-kanal, implementerad i Golang, eller i standard C++ med en uppdaterad version av OpenSSL, som vi pratade om i föregående del av artikeln. I allmänhet finns det ingen gräns för fantasin.

Exemplet med tunneln och CloudFlare presenteras som ett koncept och det är svårt att säga om de långsiktiga utsikterna för den här typen av domänfronting. För närvarande implementeras eSNI-stöd endast av CloudFlare och i teorin hindrar ingenting dem från att inaktivera denna typ av fronting och till exempel bryta TLS-anslutningar när SNI och eSNI inte matchar. Nå, framtiden får utvisa det. Men för tillfället ser utsikten att arbeta under "kremlin.ru:s täckmantel" ganska lockande ut. Är det inte rätt?

Den uppdaterade tunnelerkoden, såväl som kompilerade körbara exe-filer, placeras i en separat gren av projektet på github. Det är bättre att skriva ett ärende om alla möjliga tunnelproblem på projektsidan på GitHub.

Källa: will.com