15.05.2010
A Quick Look at the Expl:Win/HTTP.URL.XSS!0000-0000 Signature from Forefront TMG 2010 NIS

 - 1. Intro
 - 2. Quick Simple Tests
 - 3. Simple Test Using an Wordpress XSS
 - 4. Extra Quick Tests
 - 5. Conclusions

 1. Intro
As you may know, to Forefront TMG 2010's NIS were added signatures to help detect commonly used exploitations against XSS and SQLi vulnerabilities.
In this article we're going to take a quick look at the XSS one.

I'm using signatures set 4.30, see Figure1(since testing the signatures set has been updated to 4.31, don't know if something was updated in respect with the XSS signature):

Figure1: Forefront TMG 2010 NIS Signatures Set Version

Let's visualize the Expl:Win/HTTP.URL.XSS!0000-0000 signature's properties, Figure2:

Figure2: Forefront TMG 2010 NIS Expl:Win/HTTP.URL.XSS!0000-0000 signature

As we can note from Figure2, the Expl:Win/HTTP.URL.XSS!0000-0000 signature is enabled by default and set to only Detect.

So if an XSS attempt is detected, TMG will not block it, just log it and create an alert, see Figure3:

Figure3: Forefront TMG 2010 NIS Alert: XSS Detected

Also, very important, we can note from Figure2 that the Expl:Win/HTTP.URL.XSS!0000-0000 signature is an Exploit type signature.
This should imply that the signature is rather focused on detecting specific exploit(s)(Forefront TMG NIS currently has three types of signatures, we're going to disect them in a future article).
This type of signature falls into the negative security model or blacklisting, which means that such a signature is in general "bypassable by design"(a specific issue with the blacklisting approach), especially when it comes down to web applications.
It might be of no use in a targeted attack(when the attacker is aware there is a TMG NIS on the path), but might help in "mass attacks". One cannot rely on such a signature type, it's just useful for defense in depth.

From the description of this signature: This signature detects commonly used exploitation techniques for cross site scripting vulnerabilities.

Now the questions that arise from here:
 - what patterns of attacks can this signature detect ?
 - is this signature too specific and thus easily bypassable by various techniques(including simple ones) ?
 - what real world value does this signature has ?
 - it worths setting it to block mode ?

Since there is little information about what this signature can detect and we do not necessarily have access to a readable version of this signature, I decided to conduct some simple tests and note the results.
After brief tests, it appears that currently this signature has low real world value, which perhaps explains why its Signature detection value is set to Low(if the Signature detection rates this aspect).
Let's take a look.

 2. Quick Simple Tests
First thing to do, try to make it kick in. I'm going to use IE8 on Windows 7 to try to trigger the signature(I've turned off IE8's XSS filter, note that IE8's XSS filter is way more capable of detecting/blocking XSS attacks than TMG NIS' Expl:Win/HTTP.URL.XSS!0000-0000 signature).

To keep it brief, we're not going to discuss here about XSS types.
At this stage we don't need a web application vulnerable to XSS, we're just going point and shoot.

Say, typical XSS example like:
http://somesite/search.asp?q=test<script>alert(xss)</script>

Successful tests, TMG detected the XSS(for the moment it matters little we are requesting nonsense):

 - Either for a GET request, Figure4:

Figure4: Forefront TMG 2010 Logs: XSS Detected

 - Or for a POST request(not using IE8 this time), Figure5:

Figure5: Forefront TMG 2010 NIS Logs: XSS Detected

Now, looking at TMG's logs, we can note that the URLs are per se, the characters < or > were not encoded within our requests(nor was the / character).
If we were to use a different browser for testing, those characters might have been automatically encoded before being submited to the web server.

So let's encode them, Figure6:

Figure6: Forefront TMG 2010 NIS Logs: XSS Not Detected

And as a result, TMG's NIS does not detect anymore the XSS, that's the hassle with the negative security model or blacklisting approach.

Apart from the inherent limitations of the blacklisting approach, it must be noted that TMG NIS' Expl:Win/HTTP.URL.XSS!0000-0000 signature is too specific.

TMG has the ability to decode the URLs, and it is able to "verify normalization"(blocking requests to a server that are double-encoded if you select the verify normalization setting, basically the HTTP filter normalizes the URL two times).
However, apparently(who knows), it looks like the URLs are passed undecoded to TMG's NIS, and this does not decode them before checking them against its signatures, and the Expl:Win/HTTP.URL.XSS!0000-0000 signature being too specific it can easily be evaded.
If you check the verify normalization setting on the needed access rule or web server publishing rule, the effect over an XSS attack would be that it can deny a double encoded URL used to perform an XSS attack(Figure7 and the example bellow). As a side effect, the verify normalization setting may block legitimate requests that contain a %.
Example of double encoded URL used to perform an XSS attack:
 - first, encode < result: %3C
 - second, encode % result: %25
 - double encoding for < final result: %253C
 - same for > and / results double encoding: %253E and %252F.

Figure7: TMG Verify URL Normalization failed: URL denied

 3. Simple Test Using an Wordpress XSS
Let's fire an XSS against a real web application vulnerable to XSS. I have handy an Wordpress blog, and recently a Wordpress plugin was found vulnerable to XSS:

 - Test with the characters < or > not encoded, Figure8, XSS detected:

Figure8: Forefront TMG 2010 NIS Logs: Wordpress XSS Detected

 - Test with the characters < or > encoded, Figure9 and Figure10, XSS not detected:

Figure9: Forefront TMG 2010 NIS Logs: Wordpress XSS Not Detected

Figure10: XSS browser side

 4. Extra Quick Tests
 - the NIS Expl:Win/HTTP.URL.XSS!0000-0000 signature is applied for both forward web proxy scenarios(like we tested above) and reverse web proxy scenarios(say for the Wordpress test I move the server hosting the Wordpress blog behind TMG and use a web server publishing rule to publish it, Figure11).

Figure11: Forefront TMG 2010 NIS Logs: XSS Detected

 - the NIS signature detects an XSS using a null byte inside the script tag if the null byte(%) is placed immediatelly after the opening tag, <%00script>alert("xss")</script>, Figure12:

Figure12: Forefront TMG 2010 NIS Logs: XSS Detected

 - the NIS signature detects an XSS using an extra < before the opening tag, <<script>alert("xss")</script>, Figure13:

Figure13: Forefront TMG 2010 NIS Logs: XSS Detected

 - the NIS signature detects(Figure14) an XSS using a construction like <scrip<script<t>alert("xss")</scri</script>pt>. This can be used, say, when on the remote end there is a blacklist XSS filter which replaces <script> or </script> with nothing, thus the result after the replacement will be <scrip<script>t> = <script> or </scri</script>pt> = </script>.

Figure14: Forefront TMG 2010 NIS Logs: XSS Detected

 - the NIS signature does not detect an XSS using "heavy encoding", say %3C%73%63%72%69%70%74%3E instead of <script>.

 - some sites can serve pages requested without an extension, a construction like http://somesite/test/example?q=test<script>alert("xss")</script> will not be detected by the NIS signature(apparently if we omit the requested web page's extension the NIS signature will fail to detect the XSS attack).

 - if we add extra characters to the closing script tag, the NIS signature will not detect such attacks.

 - if instead of script tags, one try to use for the XSS <img src="javascript:...">, looks like the NIS XSS signature will not detect such attacks.

 5. Conclusions
As we previously said, TMG NIS' Expl:Win/HTTP.URL.XSS!0000-0000 signature has a low real world value, and this is not necessarily due to the negative security model used, rather due to the signature being too specific, failing to detect very common attacks. If we take a quick look at XSSed.com, we will notice that TMG NIS' XSS signature will fail to detect most of the XSS examples from there, the URL encodings posing troubles for TMG NIS.
Nevertheless is encouraging to see Microsoft adding such a signature to TMG's NIS. I just hope the detection rate will be improved over the time.
Having low real world value is rather not worthing of setting this signature to block mode. When this signature is set to detect only, it can be used for logging or real-time monitoring/alerting.