Some time has passed since we have not visited the NIS(Network Inspection System) from TMG.
Now that Forefront TMG 2010 has reached the RC milestone, let’s have some fun with its IPS.
As you may have noticed there is a “generic signature” on it, the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature, which is of interest for a certain matter. According to its online description, “This signature detects commonly used exploitation techniques for browser based vulnerabilities.”.
You can observe from the bellow image the Signature Set Version for the NIS on the TMG 2010 RC VM in my lab, and that the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature is left currently with the default settings: is enabled and set to block:
So, at a glance, it may go three ways for this signature say while having a vulnerable browser behind Forefront TMG 2010 RC:
- a) somebody attempts to exploit a browser vulnerability and we do not have a NIS signature on the TMG for this, but the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature manages to detect and block the attempt.
- b) somebody attempts to exploit a browser vulnerability and we do not have a NIS signature on the TMG for this, and the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature does not detect the attempt, thus the exploit might be successful as it would not be matched by any NIS signatures(unless the Malware inspection does not kick in in the first place, or maybe there is some client side protection too, etc.).
- c) the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature blocks “innocent” traffic(well, Microsoft say that “NIS enables blocking of classes of attacks while minimizing false positives”, so until proved otherwise we will give them credit).
However, none of the above is the subject of this blog post. Instead I want to discuss another possibility(in the limit that, as writing, we do not really have an “open access” to the NIS signatures on TMG Forefront RC).
Looking more carefully we may have another two possibilities:
- d) somebody attempts to exploit a browser vulnerability and we do have a NIS signature on the TMG for this which actually is capable of detecting this attack, but the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature kicks in and detects the attempt instead of the specific signature and based on the state of this signature(default block), the NIS will apply the required action.
- e) somebody attempts to exploit a browser vulnerability and we do have a NIS signature on the TMG for this which misses this attack, but the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature kicks in and detects the attempt and based on the state of this signature(default block), the NIS will apply the required action.
Before we proceed and talk about case d) which is the possibility I want to discuss, bellow I’ve triggered the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature for case a), more specifically attempting to “exploit” MS08-078(don’t get too excited, this generic signature may be not that good, if I play(change) a little with the payload of the exploit the signature is no longer triggered), note that I’ve disabled the Malware Inspection to make sure it will not interfere:
Let’s talk about case d) now.
Let’s attempt to “exploit” MS06-057, which relates to the WebViewFolderIcon ActiveX control.
We have a signature on TMG 2010 RC for this, the Expl:Win/ActiveX.WebViewFolderIcon.RCE!2006-3730 signature, see its online description, by default is enabled and set to block:
Let’s attempt to “exploit” a vulnerable host behind TMG 2010 RC, keep in mind that the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature is enabled and set to bock(default settings), also note that I’ve disabled the Malware Inspection to make sure it will not interfere.
As can be seen from bellow, the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature detects and block the “attack”, and not the Expl:Win/ActiveX.WebViewFolderIcon.RCE!2006-3730 one as one may expect:
If I disable the the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature to check if the Expl:Win/ActiveX.WebViewFolderIcon.RCE!2006-3730 signature actually detects the “attack”:
And try again, this time the Expl:Win/ActiveX.WebViewFolderIcon.RCE!2006-3730 signature detects and block the “attack”:
So what we have above may be a case of “overlapping signatures”, and the inconvenient may be that the “generic signature” blocks the “attack” instead of the needed signature.
Why I say is a potential inconvenient ?
This may relate to the state of a signature which can be: block, Detect only, disabled. More specifically the Detect only state is of interest.
What if an administrator being uncertain of this “generic signature”, sets its state to Detect only and assumes(let’s ignore for a moment that assumption is the mother of all fuck ups, yeah I know this line is from a movie with Seagal :) ) he is protected by the Expl:Win/ActiveX.WebViewFolderIcon.RCE!2006-3730 signature in case of MS06-057(we’re interested in this due to the behavior pictured above and due to the fact we have some code that allows us to trigger this behavior) ?
So set the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature to Detect only:
And try again, as can be seen(the logs look a little bit weird I would say) the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature detected the “attack” and the server’s response was allowed based on the state of the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature which was set only to detect and not to block, apparently the Expl:Win/ActiveX.WebViewFolderIcon.RCE!2006-3730 signature did not “kick in” to detect and block the attack(as the administrator assumed):
Which resulted in the client being “p0wned”, the calculator was opened(I can change the payload and have the client do something else, poke around with other “common” payloads, in this case, different for the MS08-078 situation from above, the Expl:Win/Browser.Shellcode.RCE!0000-0000 signature still kicked in, note that we are not specifically interested in payload types, just in the behavior when a signature(possibly a generic one) set to detect only is applied while there is a signature(possibly a specific one) set to block that could actually block the attack, but this signature is not actually applied for some reasons, thus the malicious traffic is allowed by the TMG 2010 RC NIS through):
So, as we saw, in this case an assumption might proved to be the mother of a fuck up.
Another potential case of “overlapping signatures”, but not between a “generic signature” and a specific one, and actually between two “specific” signatures, might be the one of the NIS signatures for MS07-020 (the Expl:Win/Agent.agentCharactersLoad.RCE!2007-1205 signature, see its online description) and MS07-051(the Expl:Win/Agent.agentCharactersLoad.RCE!2007-3040 signature, see its online description, -as writing this link leads to nowhere-), note that this is just a hunch of mine from the past, I have not played with these signatures and Forefront TMG 2010 RC so I won’t comment on this now, just mention it:
