Simplifying Domain Fronting

[Nytro]

Tim MalcomVetter

Red Team Leader at Fortune 1. I left my clever profile in my other social network: https://www.linkedin.com/in/malcomvetter

Aug 3

Simplifying Domain Fronting

Like many things in InfoSec, we complicate concepts with new terms and lingo, but the concepts at their core are simple. “Domain Fronting” is a great example.

Domain fronting is a new(ish) technique attackers are using for hiding their command and control traffic to infected computers by masquerading as traffic to trusted servers hosted behind Content Delivery Networks (CDNs). This concept can appear so confusing, but when boiled down to its core, it’s simple: there are two “addresses” for the command and control server and the attacker mismatches them in a careful way. That’s it.

Let’s break it down.

 

The first “address” is obvious: the DNS domain name which is passed in each URL, e.g. http://www.example.com. For a normal self-hosted website (no CDN), the HTTP request would look something like this:

GET /path/file.html HTTP/1.1

Host: www.example.com

…snip…

The second “address” is the host header in the HTTP request header (above). In this simplest case, the DNS domain and the host header match.

But the host header can mismatch, often by design, especially when the website is hosted behind a CDN. Let’s assume the website owners move www.example.com behind a fake CDN service called examplecdn.com. Clients still send traffic to http://www.example.com as the CDN will be transparent to them, but the CDN assigns a unique host header to the website owners so that the CDN knows to retrieve their site content and not another CDN customer’s content. Let’s assume that host header is abc.examplecdn.comwhich makes a request like this:

GET /path/file.html HTTP/1.1

Host: abc.examplecdn.com

…snip…

The first address of http://www.example.com stays the same. The second “address” (the host header) is now intentionally mismatched, but the website operates as intended — nothing malicious yet.

An attacker can exploit this scenario by first signing up for the CDN service (which is typically inexpensive). Let’s assume the CDN assigns the host header value of xyz.examplecdn.com to the attacker. An attacker can masquerade as the trusted server at http://www.example.com by simply configuring infected clients to use the attacker’s host header, so a request would look like this:

GET /path/file.html HTTP/1.1

Host: xyz.examplecdn.com

…snip…

That’s it. It’s just swapping in the attacker’s host header. Simple enough, if the conditions are right, and the attacker can enumerate those conditions through open source intelligence (OSINT), namely: which websites use which CDNs and how to setup service behind the target CDN. In fact, that’s the hardest part of the attack — finding a good domain to masquerade behind that fits the victim.

Sprinkle in HTTPS and there’s sort of a mini “race condition” that can be exploited because the encryption happens earlier since it sits at a lower layer in the OSI stack than the HTTP protocol. Not to mention that encryption can make defense more difficult (defenders must decrypt all traffic to inspect internally).

These are the steps for HTTPS traffic:

 

1. Client performs DNS lookup of server (www.example.com)

2. Client initiates a connection to the IP address from the DNS lookup on TCP port 443

3. The server presents a server certificate to begin the TLS tunnel setup

a. At this step, the server must anticipate which certificate name the client wants based on the IP address of the server. In this case, the server presents a certificate with www.example.com and not examplecdn.com or someotherexample.com. Virtual hosting multiple websites over HTTPS requires unique IP addresses per VHOST (or wildcard certificates) because TLS/SSL happens before HTTP.

4. The client completes TLS negotiation and submits the first HTTP request, optionally with a host header defined.

5. The server reads the request and may make decisions to present different content based on the value of the host header.

Step #5 is when Domain Fronting happens — since attackers simply switch in their host header for the CDN to route what appears to be trusted website traffic to their command and control server instead.

 

Many CDNs label this as a “feature” not a “bug,” but the CDNs are in the best place to prevent the abuse — it’s very difficult for a defender to detect domain fronting, because it requires decrypting all HTTPS connections, logging host headers, and checking for anomalies, which will be prone to false positives (not to mention this requires a ton of data to be collected). A better defensive approach is to simply decrypt all traffic and look for signs of command and control traffic, such as common URL patterns or predictable patterns in the call backs.

So that’s it. When you hear “domain fronting” just think: swapping in an attacker’s host header for HTTP traffic to a high reputation website hosted behind a CDN.

 

Sursa: https://medium.com/@malcomvetter/simplifying-domain-fronting-8d23dcb694a0