=====[BEGIN-ACROS-REPORT]===== ========================================================================= ACROS Security Problem Report #1999-11-10-1-PUB ------------------------------------------------------------------------- Processing of illegal URL hexadecimal encodings in IIS 4.0 ========================================================================= FULL REPORT PUBLIC ====== Affected System(s): Microsoft IIS 4.0 Problem: Processing of illegal URL hexadecimal encodings Severity: None (direct) Very high (in conjunction with other software) Solution: Installing the vendor's patch Discovered: November 10, 1999 Vendor notified: November 10, 1999 Last update: - Published: December 22, 1999 SUMMARY ======= During a penetration test our team has discovered an undocumented superfluous functionality in Microsoft Internet Information Server 4.0 that by itself (as far as we know) poses no threat to the server but can induce severe vulnerabilities through other software not being aware of it (especially security software). PROBLEM ======= According to RFC 1738, section 2.2., web servers must process hexadecimaly encoded characters in form of "%" followed by two hexadecimal digits. RFC defines these digits to be from "0123456789ABCDEFabcdef". Of course, IIS does process these encoded characters as required but we have found that it also accepts non-hexadecimal "digits" and decodes such encodings to different characters. In further text hexadecimal encodings containing at least one non-hexadecimal "digit" will be referred to as 'illegal hexadecimal encodings'. IIS 4.0 either decodes an illegal hexadecimal encoding into one character or doesn't decode it at all. Note: the only evidence of decodings we had were log files so it is possible we might have missed something. Some examples of illegal hexadecimal encodings along with their IIS decodings are: %3P --> I %2H --> 1 %1U --> . %1V --> / %GG --> %GG (no decoding) Note that "digits" in illegal hexadecimal encodings are also case insensitive (as in legal hexadecimal encodings). As noted before, this superfluous functionality to our knowledge poses no direct threat to the IIS server or underlying OS but there are cases where a serious vulnerability can be introduced, such as in these examples: 1) SecurID agent for IIS by RSA Security ---------------------------------------- SecurID Agent is an ISAPI filter providing SecurID authentication for accessing protected web folders on IIS. This filter intercepts all URL requests by clients and determines, based on them, whether SecurID authentication is required for the requested documents. This decision is based solely on the contents of the requests and currently, SecurID Agent for IIS is not aware of illegal hexadecimal encodings and can be thus tricked to pass requests for protected documents without requiring SecurID authentication. For IIS sites relying on SecurID Agent's protection this can obviously mean a huge vulnerability. 2) Intrusion detection systems ------------------------------ Network based Intrusion Detection Systems can be set to detect requests for some web documents (e.g. /msadc/msadcs.dll) that can indicate possible intrusion attempts. Obviously, network based IDSs that are unaware of IIS's processing of illegal hexadecimal encodings will fail to recognize such "adjusted" requests. Host based IDSs are not affected if they operate on data already processed by IIS, otherwise they are. Note: the list is by no means exhaustive and more vulnerable systems are likely to be found. EXAMPLE ======= Assume we have IIS 4.0 server hosting a document: https://www.someiis40server.com/confidential/secret.doc Folder '/confidential' is protected with SecurID Agent for IIS which is supposed to require SecurID authentication when a client wants to access documents in it. When properly configured, opening the above URL will produce a SecurID PASSCODE Request. Now, using illegal hexadecimal encodings this document is also accessible through, for example: https://www.someiis40server.com/conf%3Pdential/secret.doc This time, SecurID Agent will not know that IIS converts '%3P' into 'I' and will therefore also not know that the folder in request is in fact '/confidential'. Hence it will immediately pass the request on to IIS for processing. Consequently, IIS will return the document 'secret.doc' to a client without SecurID authentication. Another possible URL that will bypass SecurID Agent is: https://www.someiis40server.com/confidential%1V/secret.doc Note that SecurID Agent is properly decoding and regarding legal hexadecimal encodings, so the following request is properly processed and SecurID authentication is required (although in both cases an encoding for '/' is used): https://www.someiis40server.com/confidential%2F/secret.doc SOLUTION ======== Microsoft has provided a patch for this issue, which is downloadable from: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=16357 (Intel) or http://www.microsoft.com/Downloads/Release.asp?ReleaseID=16358 (Alpha). This patch, as far as we have tested it, corrects the identified flaw. WORKAROUND ========== There is, to our knowledge, no administrative workaround for this issue. ADVISORY ======== Administrators of IIS4 web servers are advised to either: 1) Install the Microsoft's patch or 2) Upgrade to IIS5. Both actions will remove the vulnerability. It should be noted that while this vulnerability only affects various security add-on products and intrusion detection products and you are at the moment not using any of them, it could nevertheless be smart to neutralize the flaw since there is a great chance it will be forgotten about when/if you later decide to deploy such systems. TESTING RESULTS =============== Tests were performed on: IIS 3.0 (NT4 SP3) - not affected IIS 4.0 (NT4 SP4) - affected IIS 5.0 (W2000 Server Beta Build 2301) - not affected ACKNOWLEDGMENTS =============== We would like to acknowledge Microsoft for professional response to our notification of the identified vulnerability and their help in understanding the flaw. REFERENCES ========== Microsoft has issued a Security Bulletin about this vulnerability: http://www.microsoft.com/TechNet/security/bulletin/ms99-061.asp SUPPORT ======= For further details about this issue please contact: Mr. Mitja Kolsek ACROS, d.o.o. Stantetova 4 SI - 2000 Maribor, Slovenia phone: +386 41 720 908 e-mail: mitja.kolsek@acros.si PGP Key available at PGP.COM's key server. PGP Fingerprint: A655 F61C 5103 F561 6D30 AAB2 2DD1 562A DISTRIBUTION ============ This report was sent to: - ACROS client mailing list DISCLAIMER ========== The information in this report is purely informational and meant only for the purpose of education and protection. ACROS, d.o.o. shall in no event be liable for any damage whatsoever, direct or implied, arising from use or spread of this information. All identifiers (hostnames, IP addresses, company names, individual names etc.) used in examples and exploits are used only for explanatory purposes and have no connection with any real host, company or individual. In no event should it be assumed that use of these names means specific hosts, companies or individuals are vulnerable to any attacks nor does it mean that they consent to being used in any vulnerability tests. The use of information in this report is entirely at user's risk. COPYRIGHT ========= (c) 1999 ACROS, d.o.o., Slovenia. Forwarding and publishing of this document is permitted providing all information between marks "[BEGIN-ACROS-REPORT]" and "[END-ACROS-REPORT]" remains unchanged. =====[END-ACROS-REPORT]=====