TLS 1.3을 기반으로 한 도메인 프론팅. 2 부

소개

첫 번째 부분 조항 암호화된 SNI(eSNI) 메커니즘에 대해 간략하게 설명했습니다. 그들은 이를 기반으로 최신 DPI 시스템(Beeline DPI 및 금지된 RKN 루트 추적기의 예를 사용하여)에 의한 탐지를 회피하는 것이 어떻게 가능한지 보여주고 이 메커니즘을 기반으로 하는 도메인 프론팅의 새로운 버전도 탐색했습니다.

기사의 두 번째 부분에서는 RedTeam 전문가가 어려운 작업을 수행하는 데 도움이 될 보다 실용적인 내용으로 넘어갈 것입니다. 결국 우리의 목표는 차단된 리소스에 액세스하는 것이 아닙니다(이런 사소한 일을 위해 우리는 오래된 VPN을 사용하고 있습니다). 다행히도 모든 취향, 색상, 예산에 맞는 매우 다양한 VPN 제공업체가 있습니다.

우리는 Cobalt Strike, Empire 등과 같은 최신 RedTeam 도구에 도메인 프론팅 메커니즘을 적용하고 최신 콘텐츠 필터링 시스템을 모방하고 회피할 수 있는 추가 기능을 제공하려고 노력할 것입니다.

지난번에 우리는 eSNI 메커니즘을 OpenSSL 라이브러리에 구현하고 이를 친숙한 컬 유틸리티에서 성공적으로 사용했습니다. 하지만 치킨 한 마리로는 만족할 수 없다는 말이 있죠. 물론 고급 언어에서도 비슷한 것을 구현하고 싶습니다. 그러나 불행히도 eSNI 메커니즘에 대한 지원은 GOLANG에서만 완전히 구현되기 때문에 인터넷을 통한 빠른 검색은 우리를 실망시킵니다. 따라서 선택의 여지가 많지 않습니다. 패치된 OpenSSL 라이브러리를 사용하여 순수 C 또는 C++로 작성하거나 CloudFlare에서 별도의 GOLANG 포크를 사용하여 도구를 거기로 포팅하려고 합니다. 원칙적으로 Python에 대한 eSNI 지원을 구현하는 더 고전적이지만 동시에 시간이 많이 걸리는 또 다른 옵션이 있습니다. 결국 Python은 OpenSSL을 사용하여 https를 처리합니다. 그러나 우리는 이 옵션을 다른 사람이 개발하도록 남겨두고 Golang의 구현에 만족할 것입니다. 특히 우리가 사랑하는 Cobalt Strike가 타사 도구로 구축된 통신 채널(외부 C2 채널)과 완벽하게 작동할 수 있기 때문입니다. - 이에 대해서는 기사 마지막 부분에서 이야기하겠습니다.

더 열심히 노력해보세요...

Go에서 구현된 도구 중 하나는 네트워크로의 전환을 위한 개발입니다. RSockstun, 그런데 이제 Microsoft와 Symantec의 도구에서는 글로벌 안정성을 방해하는 것을 목표로 하는 매우 악의적인 소프트웨어로 감지됩니다.

이 경우에도 이전 개발을 사용하는 것이 좋을 것입니다. 그러나 여기서 작은 문제가 발생합니다. 사실 처음에는 rsockstun이 서버와의 동기식 SSL 통신 채널 사용을 의미합니다. 이는 연결이 한 번 설정되고 터널이 작동하는 전체 기간 동안 존재함을 의미합니다. 그리고 아시다시피 https 프로토콜은 이 작동 모드용이 아닙니다. 이는 각각의 새로운 http 요청이 새로운 TCP 연결 내에 존재하는 요청-응답 모드에서 작동합니다.

이 방식의 가장 큰 단점은 클라이언트가 새로운 http 요청을 보낼 때까지 서버가 클라이언트에 데이터를 전송할 수 없다는 것입니다. 그러나 다행스럽게도 이 문제를 해결하기 위한 많은 옵션이 있습니다. 즉, http 프로토콜을 통한 데이터 스트리밍(결국 우리는 어떻게든 우리가 좋아하는 TV 프로그램을 시청하고 https에서 실행되는 포털에서 음악을 들을 수 있지만 비디오 및 오디오 전송은 다른 것이 아닙니다. 스트리밍 데이터보다). HTTP 프로토콜을 통해 본격적인 TCP 연결 작업을 에뮬레이션하는 기술 중 하나는 WebSockets 기술이며, 이 기술의 주요 본질은 클라이언트와 웹 서버 간의 본격적인 네트워크 연결을 구성하는 것입니다.

운 좋게도(만세!!!) 이 기술은 모든 CloudFlare 요금제에 기본적으로 포함되어 있으며 eSNI와 함께 사용하면 훌륭하게 작동합니다. 이것이 바로 터널러에게 도메인 프론팅을 사용하고 최신 DPI로부터 숨기도록 가르치는 데 사용할 것입니다.

WebSocket에 대해 조금

우선, 모든 사람이 우리가 무엇을 할 것인지에 대한 아이디어를 가질 수 있도록 웹소켓에 대해 간단하고 간단한 말로 이야기하겠습니다.

Websocket 기술을 사용하면 설정된 TCP 연결을 끊지 않고 일시적으로 http 연결에서 표준 네트워크 소켓 스트리밍으로 전환할 수 있습니다. 클라이언트가 웹소켓으로 전환하려고 하면 http 요청에 여러 http 헤더를 설정합니다. 두 개의 필수 헤더 - 연결: 업그레이드 и 업그레이드: 웹소켓. 또한 웹소켓 프로토콜 버전을 강제로 지정할 수도 있습니다(Sec-Websockset-버전: 13) 및 base64 웹소켓 식별자(Sec-WebSocket-키: DAGDJSiREI3+KjDfwxm1FA==). 서버는 http 코드 101 스위칭 프로토콜로 그에게 응답하고 헤더도 설정합니다. 연결, 업그레이드 и Sec-WebSocket-수락. 전환 프로세스는 아래 스크린샷에 명확하게 나와 있습니다.

그러면 WebSocket 연결 설치가 완료된 것으로 간주될 수 있습니다. 클라이언트와 서버 모두의 모든 데이터는 이제 http가 아닌 WebSocket 헤더(바이트 0x82로 시작)와 함께 제공됩니다. 이제 서버는 클라이언트의 데이터 전송 요청을 기다릴 필요가 없습니다. TCP 연결이 끊어지지 않았습니다.

Golang에는 웹소켓 작업을 위한 여러 라이브러리가 있습니다. 그 중 가장 인기있는 것은 고릴라 웹소켓 표준 웹 소켓. 우리는 후자를 사용할 것이기 때문에... 더 간단하고 작으며 그들이 말하는 것처럼 조금 더 빠르게 작동합니다.

rsockstun 클라이언트 코드에서 net.dial 또는 tls.dial 호출을 해당 WebSocket 호출로 바꿔야 합니다.

우리는 터널의 클라이언트 부분을 범용으로 만들고 직접 SSL 연결과 WebSockset 프로토콜을 통해 모두 작동할 수 있게 만들고 싶습니다. 이를 위해 별도의 함수를 만들겠습니다. func connectForWsSocks(주소 문자열, 프록시 문자열) 오류 {...} 비유로 커넥트포삭스() 클라이언트를 시작할 때 지정된 서버 주소가 ws: 또는 wss:(Secure WebSocket의 경우)로 시작하는 경우 웹 소켓 작업에 이를 사용합니다.

터널의 서버 측에서는 웹 소켓 작업을 위한 별도의 기능도 만들 것입니다. http 클래스의 인스턴스를 생성하고 http 연결 핸들러(wsHandler 함수)를 설정합니다.

그리고 모든 연결 처리 로직(비밀번호를 사용한 클라이언트 인증, yamux 세션 설정 및 종료)을 WebSocket 연결 핸들러에 배치합니다.

프로젝트를 컴파일하고 서버 부분을 시작합니다.

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

그리고 클라이언트 부분은 다음과 같습니다.

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

그리고 로컬 호스트에서 작업을 확인합니다.

도메인 프론팅으로 넘어가겠습니다.

우리는 웹소켓을 알아낸 것 같습니다. 이제 eSNI 및 도메인 프론팅으로 직접 이동해 보겠습니다. 앞서 언급했듯이 DoH 및 eSNI와 협력하려면 회사에서 특별한 golang 지점을 가져와야 합니다. CloudFlare. eSNI를 지원하는 지점(pwu/esni)이 필요합니다.

로컬로 복제하거나 해당 zip을 다운로드하여 압축을 풉니다.

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

그런 다음 GOROOT 디렉터리를 복사하고 복제된 분기에서 해당 파일을 교체하고 이를 마스터로 설정해야 합니다. 이러한 골치 아픈 문제로부터 개발자를 구하기 위해 CloudFlare 직원은 특별한 스크립트인 _dev/go.sh를 준비했습니다. 우리는 그것을 시작합니다. makefile과 함께 스크립트는 모든 것을 스스로 수행합니다. 재미삼아 makefile 내부에서 자세한 내용을 살펴볼 수 있습니다.

스크립트를 실행한 후 프로젝트를 컴파일할 때 스크립트에서 준비한 로컬 디렉터리를 GOROOT로 지정해야 합니다. 우리의 경우에는 다음과 같습니다:

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

다음으로, 원하는 도메인에 대한 공개 eSNI 키를 요청하고 구문 분석하는 기능을 터널에 구현해야 합니다. 우리의 경우 이는 CloudFlare 프런트엔드 서버의 공개 eSNI 키입니다. 이를 위해 다음 세 가지 기능을 만듭니다.

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

원칙적으로 기능의 이름은 그 자체로 나타납니다. tls-tris의 일부인 esni_query.go 파일에서 콘텐츠를 가져옵니다. 첫 번째 기능은 DoH(DNS-over-HTTPS) 프로토콜을 사용하여 CloudFlare DNS 서버에 대한 요청으로 네트워크 패킷을 생성하고, 두 번째 기능은 쿼리 결과를 구문 분석하여 도메인의 공개 키 값을 가져오고, 세 번째 기능은 처음 두 개를 위한 컨테이너입니다.

다음으로 새로 생성된 함수에 웹 소켓 연결을 추가합니다. connectForWs양말 도메인에 대한 eSNI 키를 요청하는 기능입니다. 서버 부분이 작동하는 경우 TLS 매개변수를 설정하고 가짜 "커버 도메인"의 이름도 설정합니다.

여기서는 처음에 tls-tris 분기가 도메인 프론팅을 사용하도록 설계되지 않았다는 점에 유의해야 합니다. 따라서 가짜 서버 이름에 주의를 기울이지 않습니다(빈 serverName 필드가 client-hello 패킷의 일부로 전송됨). 이 문제를 해결하려면 해당 FakeServerName 필드를 TlsConfig 구조에 추가해야 합니다. 구조의 표준 ServerName 필드를 사용할 수 없습니다. 이는 내부 TLS 메커니즘에 의해 사용되며 원래 메커니즘과 다른 경우 TLS 핸드셰이크는 오류와 함께 종료됩니다. TlsConfig 구조에 대한 설명은 파일에 포함되어 있습니다. TLS/common.go - 우리는 그것을 고쳐야 합니다:

또한 파일을 변경해야 합니다. tls/handshake_client.goTLS 핸드셰이크를 구성할 때 FakeServerName 필드를 사용하려면 다음을 수행하세요.

그게 다야! 프로젝트를 컴파일하고 작업 내용을 확인할 수 있습니다. 하지만 스캔을 실행하기 전에 CloudFlare 계정을 설정해야 합니다. 글쎄요, 어떻게 설정한다고 말할 수 있을까요? cloudflare에 계정을 만들고 도메인을 여기에 연결하면 됩니다. DoH, WebSocket 및 ESNI와 관련된 모든 기능은 기본적으로 CloudFlare에 포함되어 있습니다. DNS 레코드가 업데이트된 후 eSNI 키를 쿼리하여 도메인의 작동을 확인할 수 있습니다.

dig +short txt _esni.df13tester.info 

귀하의 도메인과 비슷한 것이 보이면 모든 것이 제대로 작동하고 테스트를 진행할 수 있다는 의미입니다.

시작하다 Ubuntu 예를 들어 DigitalOcean의 VPS를 생각해 보세요. 참고로, 저희의 경우 제공업체로부터 받은 VPS IP 주소가 러시아 연방 통신감독청(Roskomnadzor)의 블랙리스트에 올라갔습니다. 따라서 비슷한 일이 발생하더라도 놀라지 마세요. 저는 VPS에 접속하기 위해 VPN을 사용해야 했습니다.

이미 컴파일된 rsockstun을 VPS에 복사하고(이것은 Golang의 또 다른 장점입니다. 시스템의 비트 용량만 관찰하면서 프로젝트를 직접 컴파일하고 모든 Linux에서 실행할 수 있습니다) 서버 부분을 시작합니다.

그리고 클라이언트 부분은 다음과 같습니다.

보시다시피 클라이언트는 websocket을 사용하여 CloudFlare 프런트엔드 서버를 통해 서버에 성공적으로 연결되었습니다. 터널이 터널과 정확히 동일하게 작동하는지 확인하려면 서버에서 열어 로컬 sock5를 통해 컬 요청을 할 수 있습니다.

이제 DPI가 통신 채널에서 무엇을 보는지 살펴보겠습니다.

먼저, DoH 메커니즘을 사용하는 터널러는 대상 도메인(패킷 번호 1-19)의 eSNI 키를 위해 Cloudflare DNS 서버에 접속한 다음 프런트엔드 서버에 접속하고 도메인 뒤에 숨어 TLS 연결을 설정합니다. www.google.com (클라이언트 시작 시 가짜 도메인을 지정하지 않은 경우의 기본값입니다.) 가짜 도메인을 지정하려면 -fronfDomain 매개변수를 사용해야 합니다.

이제 한 가지 더. 기본적으로 CloudFalre 계정 설정은 유연한 SSL로 설정되어 있습니다. 이는 클라이언트에서 Cloudflare 프런트엔드 서버로 보내는 https 요청이 암호화되지 않은(http) 서버로 전달된다는 의미입니다. 이것이 바로 터널의 서버 부분을 비 SSL 모드( -listen ws:0.0.0.0)가 아닌( -listen wss:0.0.0.0)에서 시작한 이유입니다.

전체 암호화 모드로 전환하려면 다음을 선택해야 합니다. 가득 찬또는 전체(엄격) 서버에 실제 인증서가 있는 경우. 모드를 전환하면 https 프로토콜을 사용하여 CloudFlare의 연결을 수락할 수 있습니다. 터널의 서버측에 대해 자체 서명된 인증서를 생성하는 것을 잊지 마십시오.

호기심 많은 독자는 이렇게 질문할 것입니다. "그럼 아래 고객은 어떻게 되는 거죠?" Windows"결국 터널러의 주된 용도는 회사 컴퓨터와 서버에서 백엔드 연결을 설정하는 것인데, 이러한 시스템은 대개 Windows입니다. 특정 TLS 스택을 사용하여 Windows용 터널러를 어떻게 컴파일할 수 있을까요?" 이제 Golang의 편리함을 보여주는 또 다른 기능을 소개하겠습니다. Kali Linux에서 GOOS=windows 매개변수를 추가하기만 하면 Windows용으로 직접 컴파일할 수 있습니다.

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

또는 32비트 버전:

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

모두! 그리고 더 이상 번거로움이 필요하지 않습니다. 실제로 작동한다!

–w 및 –s 컴파일러 플래그는 실행 파일에서 불필요한 쓰레기를 제거하여 몇 메가바이트 더 작게 만드는 데 필요합니다. 또한 UPX를 사용하여 패키징하여 크기를 더욱 줄일 수 있습니다.

대신 결론

기사에서 Golang으로 작성된 터널의 예를 사용하여 TLS 1.3 프로토콜의 다소 흥미로운 기능을 구현한 새로운 도메인 프론팅 기술의 사용을 명확하게 보여주었습니다. 비슷한 방식으로 Golang으로 작성된 기존 도구를 조정하여 CloudFlare 서버를 통해 작동할 수 있습니다. 예를 들어 도끼로 찍어 죽이다 - 유명한 C2 또는 Teamserver를 통해 작업할 때 CobaltStrike Beacon이 eSNI 도메인 프론팅을 사용하도록 강제합니다. 외부 C2 채널, Golang에서 구현되거나 기사 마지막 부분에서 설명한 OpenSSL 패치 버전을 사용하여 표준 C++에서 구현됩니다. 일반적으로 상상력에는 제한이 없습니다.

터널러와 CloudFlare의 예는 개념의 형태로 제시되어 있으며 이러한 유형의 도메인 프론팅의 장기적인 전망에 대해 말하기는 여전히 어렵습니다. 현재 CloudFlare만이 eSNI를 지원하며 이론적으로 이러한 종류의 프론팅을 비활성화하는 것을 막을 수 있는 방법은 없습니다. 예를 들어 SNI와 eSNI가 일치하지 않으면 TLS 연결이 끊어집니다. 일반적으로 미래가 말해 줄 것입니다. 그러나 현재로서는 "kremlin.ru 표지" 아래에서 작업할 가능성이 꽤 매력적으로 보입니다. 안 그래?

업데이트된 터널러 코드와 컴파일된 실행 파일은 다음 프로젝트의 별도 분기에 있습니다. github. GitHub의 프로젝트 페이지에 가능한 모든 터널러 문제에 대한 문제를 작성하는 것이 좋습니다.

출처 : habr.com