As you may have noticed, by default, TMG Beta 3 comes with some “trusted” sites excluded from the Malware Inspection and NIS.
Malware inspection:
NIS:
If we read the Description from the above images, we can see that all these sites are included in a Predefined domain name set used to specify the trusted Web sites …(one such set for Malware Inspection and one for NIS).
And here comes in some fine irony, there might be little doubt that these web sites are supposed to be trusted.
However a well known quote says that it’s not about the destination, it’s about the journey or so.
Anyway, what I’m saying is that unless the path to those web sites is secured(and the web server’s authenticated), then those web sites are not trusted. On a insecure path, attackers are assumed to have the ability to capture, read, modify, delete or … the messages sent between the communicating hosts. That’s why SSL/TLS is typically used to protect the data that is to be sent over an insecure path between the client and the server. In fact, TLS itself has been designed to resist certain attacks when attackers are supposed to have such abilities(same is true for IKE/IPsec for example).
So, what may happen with simple/normal HTTP traffic sent to those destinations ?
Well, short answer: it passes uninspected through TMG Beta 3’s Malware Inspection and NIS. So what, one may say, worry of getting malware from Microsoft’s web sites, what’s the chance that this to happen ?
It may be understood that this traffic itself can be altered in transit(between client and server), but was decided that it(data) does not worth to be secured with TLS. So for this traffic itself(data), this may be a risk assumed.
The transit area(an area out of your control) is located between your edge device(maybe TMG Beta 3) and the destination web server(web server presumably considered trusted). On this area virtually anything can happen.
And one more time, the question is: if you exclude simple/normal HTTP traffic sent to certain destinations from TMG Beta 3’s Malware Inspection and NIS, what could happen ?
Well, a possibility may open for a skillful and determined attacker, who may be able to circumvent the protection(Malware Inspection and NIS) provided by TMG Beta 3, meaning be like TMG Beta 3 is not there(not quite, almost from some points of view).
This risk may be something that will vary across companies, and, as usual, everyone should take the measures deemed necessary to protect their networks, if any, based on their very own analysis of risks, costs and benefits(assuming that informed decisions are to be taken).
Let’s take a look at the default excluded sites from TMG Beta 3’s Malware Inspection and NIS. As we can notice from the above screenshots and combined with the current help files, there might be some hints why are those destinations present there. But currently we are not particularly interested in that(and possibly waiting for Microsoft to argument their decision, if ever), we are more interested what can happen while the default settings are in place.
And, as we can see, *.microsoft.com is listed. This will mean that web sites of great interest, like technet.microsoft.com, social.microsoft.com, etc., are exempted from TMG Beta 3’s Malware Inspection and NIS, bellow we can spot an internal client accessing these web sites through TMG Beta 3.
So how can an attacker gain something from these exclusions ?
For example, browsers may be an appealing target for attackers because every browser, historically, had at least one vulnerability that could let a malicious web site owner to compromise a user’s computer by exploiting this vulnerability.
And 0-day vulnerabilities may appear over the time, or even when a patch is available, there still may be a time frame till a company will test and deploy the patch. Also, even if a vulnerability is privately reported to the vendor, when the vendor issues the patch, an attacker may attempt to “reverse-engineer” this patch to figure it out what the fixed vulnerability was, and if he is able to do that fast and he is able to create an exploit for this vulnerability, he may still be in the time frame till a company tests and deploys the patch and thus have time for a go.
As we already said, the web sites exempted from TMG Beta 3’s Malware Inspection and NIS are supposed to be trusted, but a determined and skilful attacker may try to mount an active MITM attack and for example alter the server’s response.
If that happen, for example, malware can pass uninspected through TMG Beta 3, hosts behind TMG Beta 3 can be compromised.
Remember that sometime ago we excluded Bing from the malware inspection(and saying there that may be have not been the most fortunate idea) ?
Bellow we can see a user performing a simple search on Google, but the server’s reply will not come for Google, instead from an attacker that successfully MITM-ed the user’s session(ignore the fact that below IE 8 was pictured, and IE 8 would have not been vulnerable to what was returned in the server’s response):
What if this user would have visited www.microsoft.com instead and this time would have used a vulnerable browser ?
As already said, the malware as a result of an attacker that successfully MITM-ed the user’s session would have passed uninspected through TMG Beta 3’s Malware Inspection and NIS. This time was pretty harmless, upon success the calculator was opened:
Obviously, a few factors come into play: the severity of the vulnerability, the window of vulnerability, the browser used and the OS on which this browser was installed, any client-side protection available(above none was used), what will happen next(for example let’s assume that there is a vulnerability, an attacker attempts to exploit that vulnerability –> he wants something in returned if he can successfully exploit it: for example if he wants to have the client to connect back to him and spawn a cmd(basic stuff), even if he tells it to connect to a “trusted” destination(from TMG’s point of view) and then intercept the communication, it may be not so simple to do that, depending on TMG’s configuration, as TMG’s web proxy is still in the way(if TMG was configured appropriately to allow only the needed protocols), and so it may have to tunnel it over HTTP or over HTTPS and if the access rules require authentication, he may need an extra step to make that happen, please note from bellow that a few “trusted” web sites were also excluded from the outbound HTTPS inspection), –this was just a simple example, an attacker may have a few possibilities and it may be hard to know what exactly he will do in the end-. And why not, we can include in the equation how the attacker will be able to actively MITM the traffic.
Thus, if you think to add a site to the TMG Beta 3’s Malware Inspection and NIS, you should think twice about that, and, depending on the situation, make sure you have some mitigation solutions in place, just in case. –;)
To exemplify the process(and to give it a more “real” feeling), I’ve made two videos, one for the Google search(test1) and one for accessing www.microsoft.com(test2).(I’ve used Wink to create them, and I’m not quite used enough with Wink to make the flash videos look pretty and smooth).
Basically I will use Burp Proxy to intercept and modify on the fly the HTTP requests and responses. So the client will forward its request to TMG Beta 3, and from TMG Beta 3 instead of going to the real web server, the HTTP requests will be intercepted on another host running Burp Proxy and forwarded to the real web server. The server’s response will arrive at the machine running Burp Proxy, it will be forwarded to TMG Beta 3 which will inspect it and then, if all looks fine, sent it to the client.
Primarily I’m interested in modifying the web server’s response.
Probably would have been more nice to automate the process, but to exemplify it, it will be fine like so.