cancel
Showing results for 
Search instead for 
Did you mean: 

Domain Fronting, Vulnerabilities and Detection, Part II

Jump to solution

I'm beginning to think that I had the wrong approach to a topic that I posted in a previous question (here), regarding Domain Fronting.  Is there a way to compare the host name for a GET or POST to that of the CONNECT in which they are tunneled?  The idea being to restrict GET's and POST's to the domain of the CONNECT, at least for those destinations with less trustworthy risk scores. 

And, this brings up a related question: are the details in the SSL certificate from the CONNECT, particularly that of CN's and alternate names, visible to the tunneled GET's and POST's?  If so, what would be a good approach to validate the current hostname to the CN and alternate names?

  

1 Solution

Accepted Solutions
McAfee Employee jscholte
McAfee Employee
Report Inappropriate Content
Message 3 of 3

Re: Domain Fronting, Vulnerabilities and Detection, Part II

Jump to solution

I found a good test for this as well as a means to detect it on MWG.

To test, here is a curl command which opens a tunnel for cnn.com, and once the tunnel is opened, requests are sent for mcafee.com instead.

curl --insecure -v -s -o /dev/null --proxy http://yourmwg:9090 -H "Host: mcafee.com" -H "Connection: close" "https://cnn.com/"

In the Web Gateway we can make use of the Connection.Variables.* events and properties to store the originally requested domain from the CONNECT request, and recall it once we're inside the tunnel to perform a test to see if the original domain matches the domain requested in the tunnel.

Now this might have some caveats, specifically related to transparent proxy. So by default these rules only apply to Explicit proxy requests. For transparent proxy requests, the MWG relies on the SNI header in order to determine the originally requested domain, so if that is not present, then the MWG would only know the destination IP, and in most cases that will result in a mismatch.

2018-08-29_094418.png2018-08-29_094450.png2018-08-29_094505.pngLet me know if you have any questions on the rules and if this helps at all. At first it might be good to just monitor to these things, then block (in case there is false positives).

 

Best Regards,

Jon

2 Replies
McAfee Employee jscholte
McAfee Employee
Report Inappropriate Content
Message 2 of 3

Re: Domain Fronting, Vulnerabilities and Detection, Part II

Jump to solution

Hi John,

So, MWG has a configuration option called "Host header has priority over original destination address (transparent proxy", this prevents situations where there is a mismatch between the Host header and the Request line. 7.8.2 brings a property called URL.DiscardedHost which is meant to help detect Domain Fronting whereby you can access the host that was discarded from the scenario above.

For the scenario you described MWG would connect to the Host from the CONNECT request, and if inside the tunnel requests are made for separate domains, MWG would see those requests assuming that SSL inspection is enabled.

So if the CONNECT was for facebook.com, and you've got something making requests to malware.com (inside the tunnel), MWG will see those requests and treat them according to your policy.

Having said this I'm not sure if we'd have the "facebook.com" context available for the requests inside the tunnel (to make sure the hosts match). Did you have a script you were using to try and recreate this scenario? This might be something I could test really quick if you did.

Best Regards,

Jon

McAfee Employee jscholte
McAfee Employee
Report Inappropriate Content
Message 3 of 3

Re: Domain Fronting, Vulnerabilities and Detection, Part II

Jump to solution

I found a good test for this as well as a means to detect it on MWG.

To test, here is a curl command which opens a tunnel for cnn.com, and once the tunnel is opened, requests are sent for mcafee.com instead.

curl --insecure -v -s -o /dev/null --proxy http://yourmwg:9090 -H "Host: mcafee.com" -H "Connection: close" "https://cnn.com/"

In the Web Gateway we can make use of the Connection.Variables.* events and properties to store the originally requested domain from the CONNECT request, and recall it once we're inside the tunnel to perform a test to see if the original domain matches the domain requested in the tunnel.

Now this might have some caveats, specifically related to transparent proxy. So by default these rules only apply to Explicit proxy requests. For transparent proxy requests, the MWG relies on the SNI header in order to determine the originally requested domain, so if that is not present, then the MWG would only know the destination IP, and in most cases that will result in a mismatch.

2018-08-29_094418.png2018-08-29_094450.png2018-08-29_094505.pngLet me know if you have any questions on the rules and if this helps at all. At first it might be good to just monitor to these things, then block (in case there is false positives).

 

Best Regards,

Jon

More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator