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?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jahboiteCommented:
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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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
Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Network Analysis

From novice to tech pro — start learning today.