Company

Technical Security Consulting

Managing Risk

Research & Development

Forensics

Security Management

Media Centre

PCI DSS

• Home
• Overview
• R&D Services
• Technology Focus
• Messaging Systems Security
• Embedded Systems Security
• Collaborative Research Projects
• Technical Whitepapers
• Research Briefings
• Publicly Released Tools
• Vendor Alerts - 0days
• Security Advisories
• Advisories
• Advisory 028
• Advisory 027
• Advisory 026
• Advisory 025
• Advisory 024
• Advisory 023
• Advisory 022
• Advisory 021
• Advisory 020
• Advisory 019
• Advisory 018
• Advisory 017
• Advisory 016
• Advisory 015
• Advisory 014
• Advisory 013
• Advisory 012
• Advisory 011
• Advisory 010
• Advisory 009
• Advisory 008
• Advisory 007
• Advisory 006
• Advisory 005
• Advisory 004
• Advisory 003
• Advisory 002
• Advisory 001

Advisory 006

The configuration of Microsoft URLScan can be enumerated when implemented in conjunction with RSA SecurID
Vulnerablity Type / Importance: Information Leakage / High

Problem discovered: July 18th 2003
Microsoft contacted: July 18th 2003
RSA contacted: August 11th 2003
Advisory published: August 13th 2003

Abstract :
URLScan is an ISAPI filter, provided by Microsoft that performs various checks on HTTP requests sent to a web server. It can be configured to block access to various file extensions, HTTP methods and potentially malicious URL sequences. SecurID is a product supplied by RSA Security to provide a two-factor authentication mechanism to prevent unauthorised access to a website. If the products are used together on the same web server and configured in a certain way then it is possible to enumerate the configuration of URLScan and hence potentially uncover malicious file extensions that may not be filtered by the product.

Description :
Recently during a penetration test IRM identified a serious security vulnerability when URLScan and SecurID are combined on the same machine.

IRM requested the following URL from the target web server:

http://server/irm.ida

Contained within the page contents that were returned was the following line:

<INPUT TYPE=HIDDEN NAME="referrer" VALUE="Z2FZ3CRejected-By-UrlScanZ3EZ3FZ7EZ2Firm.ida">

Then IRM requested the URL shown below:

http://server/irm.htm

No line relating to URLScan was returned in the page contents.

The default urlscan.ini file contains the following line:

RejectResponseUrl = ; UrlScan will send rejected requests to the URL specified here. Default is /<Rejected-by- UrlScan >

This is where the 'referrer' value that is returned originates.

As the ISAPI extension '. ida ' is associated with the Indexing service, which was exploited by the infamous Code Red worm, the engineer thought it was likely to be in the filtered extensions list within the URLScan configuration. A script was then produced to test this theory and it was demonstrated that using this technique the configuration of URLScan could be enumerated.

Microsoft were initially contacted, but were unable to reproduce the issue using just URLScan . However, when RSA Security were made aware of the vulnerability they confirmed that it was related to the interaction between the use of URLScan and SecurID and provided a simple workaround to resolve the problem.

Tested Versions:
Microsoft IIS 5
RSA ACE/Agent 5.0
URLScan 2.5

Tested Operating Systems :
Microsoft Windows 2000

Vendor & Patch Information:
RSA Security were contacted on the 11th August and on 13th August provided a workaround to resolve the issue.

Workarounds :
In Microsoft Internet Services Manager, the SecurID filter needs to be the first in the global ISAPI filter list, above URLScan .

Credits :
Research & Advisory: A Davis

Disclaimer:
All information in this advisory is provided on an 'as is' basis in the hope that it will be useful. Information Risk Management Plc is not responsible for any risks or occurrences caused by the application of this information.