W

pierwszej części poznaliśmy prostą metodę przejęcia domeny wraz z jej pozycją SEO oraz reputacją. W dzisiejszym poście omówimy technikę zwaną domain fronting. Na czym ona polega? Dla przykładu spójrzmy na jeden z adresów IP używanych przez frontowy serwer obsługujący domenę www.google.es:

host www.google.es

www.google.es has address 216.58.210.163
www.google.es has IPv6 address 2a00:1450:4003:808::2003

Jeśli przyjrzymy się bliżej polu Common Name (CN) certyfikatu TLS zwróconego przez serwer:

echo | openssl s_client -CApath /usr/lib/ssl -connect 216.58.210.163:443 | openssl x509 \
-subject

depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = google.com
subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=google.com

to przekonamy się, że nie widnieje tam domena, o którą nam chodziło – www.google.es. Czyli ten certyfikat uwierzytelnia nazwę, której nie ma w CN ? Pokopmy trochę głębiej, aby uzyskać odpowiedź:

echo | openssl s_client -CApath /usr/lib/ssl -connect 216.58.210.163:443 | openssl x509 \
-text

       X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name:
                DNS:google.com, DNS:*.2mdn.net, DNS:*.android.com, DNS:*.google.ch

Za wszystkim stoi rozszerzenie SAN – Subject Alternative Name umożliwiając serwowanie więcej niż jednej strony z tego samego adresu IP za pomocą protokołu HTTPS (patrz: Zapalmy flarę nad Cloudflare). Możemy użyć także innego, znanego rozszerzenia protokołu TLS – SNI – Server Name Indication, aby od strony klienta poprosić o konkretny host wirtualny dostępny na tym samym adresie IP. Poprośmy więc o mail.google.com:

echo | openssl s_client -CApath /usr/lib/ssl \
-connect 216.58.210.163:443 -servername mail.google.com | openssl x509 -subject

depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = mail.google.com
subject= /C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com

Okazuje się, że w przypadku Google nie musimy nawet korzystać z rozszerzenia SNI – wystarczy, że prześlemy odpowiedni nagłówek HTTP proszący o odpowiedni Host:

curl -v --header 'Host: mail.google.com' www.google.es

* Rebuilt URL to: www.google.es/
* Connected to www.google.es (2a00:1450:4007:815::2003) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.35.0
> Accept: */*
> Host: mail.google.com
>
< HTTP/1.1 301 Moved Permanently
< Location: /mail/
< Content-Type: text/html; charset=UTF-8

W ten sposób, ktoś kto monitoruje nasze otoczenie sieciowe zobaczy żądanie do strony www.google.es, a cała komunikacja z mail.google.com zostaje zamaskowana wewnątrz warstwy TLS. Jaka jest zaleta tej techniki? Skoro wiemy, że Google używa tych samych serwerów frontowych do wszystkich produktów możemy użyć tego faktu np. do komunikacji z naszym serwerem C&C, który będzie hostowany na Google App Engine w domenie pentester.appspot.com, a monitoring sieci nawet nie będzie wstanie zobaczyć żądań DNS o wspomnianą domenę – jedynym zarejestrowanym ruchem będą żądania DNS dotyczące “legalnego” i nudnego ruchu na wyszukiwarce Google. Google nie jest jedynym takim przypadkiem – bardzo wielu “dużych” dostawców CDN, jak Microsoft Azure, Amazon Cloudfront, S3, Fastly, czy Akamai może zostać wykorzystana, do tego typu nadużyć.

Więcej informacji: High-reputation Redirectors and Domain Fronting, Escape and Evasion Egressing Restricted Networks, Blocking-resistant communication through domain fronting, Signal implements ‘domain fronting’ technique to bypass censorship, Camouflage at encryption layer: domain fronting