Domänfronting baserat på TLS 1.3. Del 2

Introduktion

I den första delen artiklar gav vi en kort beskrivning av mekanismen encrypted SNI (eSNI). Vi visade hur den kan användas för att undvika upptäckter av moderna DPI-system (med exempel på Beeline DPI och den förbjudna RKN Tracker), samt att vi undersökte en ny variant av domän-fronting baserad på denna mekanism.

I den andra delen av artikeln går vi vidare till mer praktiska saker som kommer att vara till nytta för RedTeam-specialister i deras utmanande arbete. I slutändan är vårt mål inte att få tillgång till blockerade resurser (för sådana banala saker har vi den gamla goda VPN). Det finns gott om VPN-leverantörer, som man säger, för varje smak, färg och budget.

Vi kommer att försöka tillämpa mekanismen domän-fronting på moderna RedTeam-verktyg, som Cobalt Strike, Empire osv., och ge dem ytterligare möjligheter till mimickring och undvikande av moderna innehållsfilter.

Förra gången implementerade vi mekanismen eSNI i OpenSSL-biblioteket och använde den framgångsrikt i det bekanta verktyget curl. Men bara med curl, som man säger, blir man inte mätt. Naturligtvis vill vi implementera något liknande i högre nivåspråk. Men tyvärr, en snabb sökning på nätet gör oss besvikna eftersom stödet för mekanismen eSNI är fullt implementerat endast i GOLANG. Därför har vi inte mycket att välja på: antingen skriver vi i rent C eller C++ med hjälp av det patchade OpenSSL-biblioteket, eller så använder vi en separat fork av GOLANG från CloudFlare och försöker portera vårt verktyg dit. I princip finns det ett annat, mer klassiskt men samtidigt arbetskrävande alternativ – att implementera stöd för eSNI för Python. I slutändan använder Python också OpenSSL för att arbeta med https. Men detta alternativ lämnar vi till någon annan att utveckla, medan vi nöjer oss med implementationen i golang, särskilt eftersom vår älskade Cobalt Strike är bra på att använda kommunikationskanaler som byggs med tredjepartsmaterial (External C2 channel) – detta kommer vi att berätta mer om i slutet av artikeln.

Try Harder…

Ett av de Go-verktyg vi har implementerat – vår utveckling för pivoting in i nätverket – tunneln rsockstun, som för övrigt numera identifieras av Microsofts och Symantecs verktyg som mycket skadlig programvara som syftar till att störa den globala stabiliteten…

Det skulle vara bra att använda den tidigare utvecklingen även i det här fallet. Men det finns ett litet problem. Det handlar om att rsockstun ursprungligen förutsätter användning av en synkron SSL-koppling till servern. Detta innebär att anslutningen etableras en gång och finns kvar under hela tunneleens driftstid. Och som ni förstår är https-protokollet inte riktigt designat för ett sådant arbetsläge – det fungerar i en begärs-svar-mod, där varje ny http-begäran existerar inom ramen för en ny tcp-anslutning.

Den största nackdelen med detta system är att servern inte kan skicka data till klienten innan klienten skickar en ny http-begäran. Men lyckligtvis finns det många alternativ för att lösa detta problem – strömmande data via http-protokollet (i slutändan lyckas vi ju på något sätt se våra favoritserier och lyssna på musik från plattformar som kör på https, och överföring av video och ljud är inget annat än strömmande data). En av teknologierna för att emulera ett fullständigt tcp-anslutning ovanpå http-protokollet är WebSockets-teknologin, vars huvudsyfte är att organisera en fullständig nätverksanslutning mellan klienten och webbservern.

Till vår lycka (hurra!!!), denna teknologi är aktiverad som standard i alla CloudFlare-abonnemang och fungerar utmärkt tillsammans med eSNI. Det är just den vi kommer att använda för att lära vår tunnel att använda domän-framåtsikt och dölja sig för moderna DPI.

Lite om WebSockets

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

WebSockets-teknologin möjliggör tillfällig växling från http-anslutning till standard strömmande data via nätverksocket, utan att bryta den etablerade tcp-anslutningen. När klienten vill växla till web socket, lägger den till några http-header i sin http-begäran. Två obligatoriska huvuden är Connection: Upgrade och Upgrade: websocket. Den kan också specificera versionen av websocket-protokollet tvingat (Sec-Websockset-Version: 13) och något som liknar base64-identifierare för webbsocketen (Sec-WebSocket-Key: DAGDJSiREI3+KjDfwxm1FA==). Servern svarar med http-kod 101 Switching Protocols och sätter även headers Connection, Upgrade och Sec-WebSocket-Accept. Processen för omkoppling visas tydligt på skärmdumpen nedan:

Efter detta kan WebSocket-anslutningen anses vara komplett. Alla data, både från klienten och servern, kommer nu att levereras med WebSocket-headers (de börjar med byte 0x82). Nu behöver inte servern vänta på en begäran från klienten för att skicka data, eftersom tcp-anslutningen inte bryts.

I Go finns det flera bibliotek för att arbeta med websockets. De mest populära av dem är Gorilla WebSocket och standardbiblioteket WebSocket. Vi kommer att använda det senare, eftersom det är enklare, mindre och fungerar, som sagt, lite snabbare.

I klientkoden för rsockstun måste vi byta ut anrop av net.dial eller tls.dial mot motsvarande WebSocket-anrop:

Vi vill göra klientdelen av vår tunnelerare universell och kunna arbeta både via en direkt ssl-anslutning och via WebSocket-protokollet. För detta kommer vi att skapa en separat funktion func connectForWsSocks(address string, proxy string) error {…} i analogi med connectForSocks() och använda den för att arbeta med websockets om serveradressen som angavs vid klientstarten börjar med ws: eller wss: (i fallet med Secure WebSocket).

För serverdelen av tunneleraren kommer vi också att göra en separat funktion för att arbeta med websockets. Där kommer en instans av http-klassen att skapas och http-anslutningens hanterare (funktionen wsHandler) ställas in:

Och all logik för att hantera anslutningen (autorisering av klienten med lösenord, upprättande och avslutande av yamux-sessionen) kommer att placeras i WebSocket-anslutningens hanterare:

Vi kompilerar projektet och kör 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 funktionen på den lokala värden:

Låt oss gå vidare till domän-fronting

Med websockets verkar vi ha förstått. Nu låt oss gå direkt till eSNI och domän-fronting. Som nämnts tidigare, för att arbeta med DoH och eSNI behöver vi ta en speciell Go-gren från företaget CloudFlare. Vi behöver en gren med stöd för eSNI (pwu/esni).

Klona den lokalt eller ladda ner och packa upp motsvarande zip-fil:

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

Därefter behöver vi kopiera katalogen GOROOT, byta ut motsvarande filer från den klonade grenen och ställa in den som huvud. För att avlasta utvecklaren har killarna på CloudFlare förberett ett speciellt skript – _dev/go.sh. Vi kör bara det. Skriptet tillsammans med makefile kommer att göra allt själv. För intressets skull – ni kan titta inuti makefile för detaljer.

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

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

Vidare behöver vi implementera i tunneln funktionen för att begära och parsa publika eSNI-nycklar för den aktuella domänen. I vårt fall kommer detta att vara de publika eSNI-nycklarna från CloudFlare:s frontendservrar. För 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)

Funktionsnamnen säger i princip sig själva. Fyllningen kommer vi att ta från filen esni_query.go, som ingår i tls-tris. Den första funktionen skapar ett nätverkspaket med en begäran till CloudFlare:s DNS-server, som använder protokollet DoH (DNS-over-HTTPS), den andra – parsar begärans resultat och får värdena av de publika nycklarna för domänen, den tredje fungerar som en behållare för de två första.

Därefter lägger vi till i vår ny skapade funktion för att ansluta till websockets connectForWsSocks funktionen för att begära eSNI-nycklar för domänen. Där serverdelen fungerar ställer vi in TLS-parametrarna, samt anger namnet på det falska "skyddsapplikationsdomänen":

Här bör vi notera att den ursprungliga gren av tls-tris inte är avsedd för användning av domänfronting. Följaktligen tillägnas inte ett falskt servernamn (i klient-hello-paketet skickas ett tomt serverName-fält). För att åtgärda detta måste vi lägga till det motsvarande fältet FakeServerName i strukturen TlsConfig. Vi kan inte använda det standardmässiga ServerName-fältet i strukturen, eftersom det används av interna TLS-mekanismer och om det skiljer sig från det ursprungliga, kommer TLS-handshaken att avslutas med ett fel. Beskrivningen av strukturen TlsConfig finns i filen tls/common.go – den måste vi justera:

Dessutom måste vi göra ändringar i filen tls/handshake_client.go, för att använda vårt fält FakeServerName vid bildandet av TLS-handskake:

Det är allt! Du kan kompilera projektet och kontrollera dess funktion. Men innan du kör kontrollerna måste du konfigurera ditt CloudFlare-konto. Hur man säger, konfigurera – bara skapa ett konto på CloudFlare och koppla din domän till det. Alla funktioner relaterade till DoH, WebSocket och ESNI är aktiverade i CloudFlare som standard. Efter att DNS-posterna har uppdaterats kan du kontrollera att din domän fungerar genom att göra en förfrågan om eSNI-nycklar:

dig +short txt _esni.df13tester.info 

Om du ser något liknande för din domän – betyder det att allt fungerar och du kan gå vidare till testningen.

Starta Ubuntu VPS, till exempel på DigitalOcean. P.S. I vårt fall visade sig den just tilldelade IP-adressen från leverantören vara på RKN:s svartlista. Så bli inte förvånad om något liknande händer dig. Vi var tvungna att använda VPN för att komma in på vår VPS.

Kopiera den redan kompilerade rsockstun till VPS (förresten, det är ännu en fördel med Go – du kan kompilera projekt på din egen maskin och köra det på vilken Linux som helst, så länge du följer systemets arkitektur) och starta serverdelen:

Och sedan klientdelen:

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

Låt oss nu se vad DPI ser i kommunikationskanalen:

Först konsulterar tunneln, med hjälp av DoH-mekanismen, CloudFlares DNS-server för eSNI-nycklar för destinationdomänen (paket nr 1-19), och sedan kontaktar den frontend-servern och etablerar en TLS-anslutning, och döljer sig bakom domänen www.google.com (detta är standardvärdet när ingen falsk domän anges vid klientens start). För att ange din egen falska domän måste du använda parametern -fronfDomain:

Nu är det en sak till. Som standard är inställningen för kontot på CloudFlare i läget Flexible SSL. Det betyder att https-förfrågningar till CloudFlares frontend-servrar från klienterna kommer att vidarebefordras i okrypterad (http) form till vår server. Därför körde vi serverdelen av tunneln i non-ssl-läge (-listen ws:0.0.0.0), snarare än (-listen wss:0.0.0.0).

För att växla till läget med full kryptering måste du välja Full, eller Full (strict) i fall med den aktuella certifikatet på servern. Efter att ha växlat läge kan vi ta emot anslutningar från CloudFlare via https-protokollet. Glöm inte att generera ett self-signed certifikat för serverdelen av tunneln.

Den nyfikna läsaren kanske frågar: "Vad sägs om klienten för Windows? Det är ju säkert så att den huvudsakliga användningen av tunneln är att etablera backconnect från företagsdatorer och servrar, och där är det som regel alltid Windows. Hur kan jag kompilera tunneln för Windows, och dessutom med en specifik TLS-stack?" Låt oss nu presentera en annan funktion som visar hur praktisk Go är. Vi kompilera för Windows direkt från Kali, helt enkelt genom att lägga till parametern GOOS=windows:

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

Eller den 32-bitars varianten:

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

Det är klart! Och inga fler komplicerade grejer behövs. Det fungerar verkligen!

Kompilatorflaggorna -w och -s behövs för att ta bort onödigt skräp från den exekverbara filen, vilket gör den mindre med ett par megabyte. Den kan dessutom packas med hjälp av UPX för att ytterligare minska storleken.

Avslutande

I artikeln visade vi, med exemplet av en tunneler skriven i Go, tydligt tillämpningen av den nya teknologin domän-framträdande, som implementerades på en ganska intressant egenskap hos protokollet TLS 1.3. På samma sätt kan man anpassa existerande verktyg skrivna i Go för att arbeta genom CloudFlare-servrar, till exempel Merlin — en känd C2, eller få CobaltStrike Beacon att använda eSNI domän-framträdande när man arbetar med Teamserver via External C2 Channel, implementerad i Go, eller på standard C++ med en patchad version av OpenSSL, som vi berättade om i den föregående delen av artikeln. Så, fantasin har inga gränser.

Exemplet med tunneln och CloudFlare presenteras som ett koncept och det är fortfarande svårt att säga något om de långsiktiga perspektiven för denna typ av domän-framträdande. För närvarande är stöd för eSNI endast implementerat av CloudFlare och, i teorin, hindrar inget dem från att stänga av denna typ av framträdande och till exempel bryta tls-anslutningar vid oöverensstämmelse mellan SNI och eSNI. Framtiden får utvisa. Men för tillfället verkar utsikten att arbeta under "skyddet av kremlin.ru" ganska lockande. Visst?

Den uppdaterade tunnelkoden samt de kompilerade exekverbara exe-filerna finns i en separat gren av projektet på github. För alla potentiella problem med tunneln är det bättre att skriva issue på projektets sida på GitHub.

Källa: habr.com