URLScan and False Logging Weakness

I have several IIS servers running either IIS 5.0 or 6.0. A security audit recently uncovered one of our 5.0 servers was exposed to this False Logging Weakness where IIS will interpret hex code as characters. The potential is that an attacker could fill the log files with garbage. URLScan was prescribed as the possible fix. The question is what setting/configuration will prevent this? I have URLScan configured on the servers.

I'm also wondering why only one server was discovered with this vulnerability exposed. All our IIS 5.0 servers have URLScan configured identically. Could this be a  case of a false positive on the scan?

Thanks in Advance
kmkrause2Asked:
Who is Participating?
 
jahboiteConnect With a Mentor Commented:
From the details you give and from a few minutes googling, I would agree with you that it could very well be a false positive.

I believe that the settings needed are
NormalizeUrlBeforeScan=1
VerifyNormalization=1

If you were able to get hold of the method by which the auditor performed the test (i.e. the exact HTTP request used), you should be able to test this for yourself by checking the logs after the request is made.  If you don't see URL encoded strings, then URLscan is doing its job.

You could get hold of something like Paros or WebScarab and formulate your own HTTP requests with hex encoded URL's and do the same.
0
 
kmkrause2Author Commented:
Thanks for the response. I'll have our auditing company run the scan again and look for their IP in the log files. We've not changed out config in some time and the past audits have not shown this to be a problem.

0
 
ahoffmannCommented:
is the reported URL one of the web server itself, or is it one from an application server behind?
0
SMB Security Just Got a Layer Stronger

WatchGuard acquires Percipient Networks to extend protection to the DNS layer, further increasing the value of Total Security Suite.  Learn more about what this means for you and how you can improve your security with WatchGuard today!

 
kmkrause2Author Commented:
> is the reported URL one of the web server itself, or is it one from an application server behind? <

It's an IP that is shared between two NLB web servers hosting a single site. Still waiting for a callback from our auditor.

Thanks
0
 
kmkrause2Author Commented:
Sorry for all the delay. The auditing company will be rescanning overnight tonight. The problem may be related to a URLScan issue. I found out that the dll was not running properly in that no log files had been generated and even though .ini file extensions were explicitly denied, they were still accessible. I removed the 2.0 version and applied the 2.5 and verified all was working properly. I'm betting the scan will not show the problem this time around.

Will update the results tomorrow.
0
 
jahboiteCommented:
Nice work!
0
All Courses

From novice to tech pro — start learning today.