Canonicalization
Canonicalization is the process by which various equivalent forms of a name can be resolved to a single, standard name - the so-called canonical name. For example, on a given machine, the names c:\dir\test.dat, test.dat, and ..\..\test.dat might all refer to the same file. Canonicalization is the process by which such names would be mapped to a name like c: \dir\test.dat.
Vulnerability
When certain types of files are requested via a specially-malformed URL, the canonicalization yields a partially-correct result. It locates the correct file, but concludes that the file is located in a different folder than it actually is. As a result, it applies the permissions from the wrong folder.
The vulnerability results because it is possible to construct an URL that would cause IIS to navigate to any desired folder on the logical drive that contains the web folder structure, and access files in it. The request would be processed under the security context of the IUSR_machinename account, which is the anonymous user account for IIS. This is the account that performs web actions on behalf of unauthenticated visitors to the site. Under normal conditions, the account only has permissions to take actions that are acceptable for general use by visitors to the site.
The danger lies in the fact that the vulnerability allows the user to escape from the web folders and access files elsewhere on the drive. By default, many of these files provide access to the everyone group and/or the Users group, both of which include the IUSR_machinename account as a member. These groups have executed permissions to most operating system commands, and this would give the malicious user the ability to cause widespread damage. This vulnerability would effectively grant the same privileges to the malicious user as are normally available to users who can log onto a machine locally.
The default permissions would allow the user to execute virtually any operating system command, and these would enable him to cause a wide array of damage. He could, for instance, create new files on the server, delete ones that are already there, or he could reformat the entire hard drive. He wouldn't be limited to misusing code that already existed on the server. Access to the operating system commands would give him the ability to upload code of his choice to the machine and execute it.
However, the vulnerability only allows files to be accessed if they reside on the same logical drive as the web folders. So, for instance, if a web administrator had configured his server so that the operating system files were installed on the C: drive and the web folders were installed on the D: drive, the malicious user would be unable to use the vulnerability to access the operating system files.
Exploit
One of the principal security functions of a web server is to restrict user requests so they can only access files within the web folders. Microsoft IIS 4.0 and 5.0 are both vulnerable to double dot "../" directory traversal exploitation if extended Unicode character representations are used in substitution for "/" and "\". This vulnerability provides a way for a malicious user to provide a special URL to the web site that will access any files whose name and location he knows, and which is located on the same logical drive as the web folders. This would potentially enable a malicious user who visited the web site to gain additional privileges on the machine - specifically, it could be used to gain privileges commensurate with those of a locally logged-on user. Gaining these permissions would enable the malicious user to add, change or delete data, run code already on the server, or upload new code to the server and run it. For instance, consider the following valid url.
Eg.
http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir
http://target/scripts/..%c0%9v../winnt/system32/cmd.exe?/c+dir
http://target/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir
http://target/scripts/..%c0%qf../winnt/system32/cmd.exe?/c+dir
http://target/scripts/..%c1%8s../winnt/system32/cmd.exe?/c+dir
http://target/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir
http://target/scripts/..%c1%pc../winnt/system32/cmd.exe?/c+dir
http://target/msadc/..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+dir
Another exploit demonstrates how an attacker can execute commands using a redirect on the target host.
- To begin, the attacker copies ".. \..\winnt\system32\cmd.exe" to "..\..\interpub\scripts\cmd1.exe"
- He appends the command to the valid URL.Vulnerable IIS returns: "CGI Error ... 1 file(s) copied."The specified CGI application does not return a complete set of HTTP headers. Instead it returns the above error.
- Next the attacker runs "cmd1.exe /c echo abc >aaa & dir & type aaa" along with the URL to list the directory contents.Vulnerable IIS returns:
" Directory of c: \inetpub\scripts 10/25/2000 03:48p
. 10/25/2000 03:48p .. 10/25/2000 03:51p 6 aaa 12/07/1999 05:00a 236,304 cmd1.exe .. abc
- ASCII characters for the dots are replaced with hexadecimal equivalent (%2E).
- ASCII characters for the slashes are replaced with Unicode equivalent (%co%af).
- Unicode 2.0 allows multiple encoding possibilities for each characters.
- Unicode for"/": 2f, c0af, e080af, f08080af, f8808080af,.....
- Overlong Unicode are NOT malformed, but not allowed by a correct Unicode encoder and decoder.
- Maliciously used to bypass filters that only check short Unicode.
Unicode extensions are installed by default with Microsoft Internet Information Server (IIS) version 4.0 and 5.0. This is to allow characters that are not used in the English language to be recognized by web servers. Computers store letters and other characters by assigning a number to them.
Unicode provides a unique number for every character. Unicode forms a single character set across all languages. It is a standard 2-byte or 3-byte character set. The IIS Unicode Exploit allows users to run arbitrary commands on the web server. IIS servers with the Unicode extensions loaded are vulnerable unless they are running current patches.
This exploit can be used when:
- A writeable or executable directory is available; allowing attackers to upload malicious code.
- A system executable such as cmd.exe is available on the root and does not have an access control list applied to it.
The attack occurs when an attacker sends a malformed URL to a web server that looks something like this:
If the target has a virtual executable directory (e.g. scripts) located on the same directory of Windows system, the directory of C: will be revealed. The question mark inserted after cmd.exe represents a command line argument.
For instance, appending a/c as in the above example, indicates that it carries out the command specified by the sub ceding string and then terminates. The "+" indicates the space between arguments. The variable /..%255c..%255c decodes to /.... which translates to a directory traversal.
This is equivalent to sending a hex value to the server. A common example is %20 which refers to a space. Using a direct hex interpretation of a directory traversal will be checked by IIS user access denied.
Still, the exploit occurs because the CGI routine within the web server decodes the address twice. First CGI filename will be decoded to check if it is an executable file (e.g. '.exe' or '.com') After the filename checkup , IIS will run another decode process. So an attacker will send various hex values of a required character till a suitable value is accepted.
Therefore '..' can be represented by '..%255c' , '..%%35c' etc. After first decoding, '..%255c' is turned into '..%5c' IIS will take it as legal character string that can pass security checkup. However, after a second decode process, it will be reverted to '..' and the attack succeeds.
In this case, the web server will just look for the file in the web root directory called "../../../../../winnt/repair/sam._". The '../' tells the web server to search one directory above, so here, the web server will look in the document root for a file called winnt/repair/sam. _. The no. of '../"s does not matter as long as there are enough of them to traverse back to the root of the file system (either c: or / on UNIX system)
The IIS Unicode exploit uses the HTTP protocol and malformed URLs to traverse directories and execute arbitrary commands on the vulnerable web servers. The IIS Unicode exploit uses a Unicode representation of a directory delimiter (/) to fool IIS. Because the exploit uses http, it works directly from the address bar of a browser. Because of the non-interactive nature of this exploit, interactive commands such as ftp & telnet do not work.
- IIS logs all the visits in log files. The log file is located at <%systemroot%>\logfiles
- Be careful. If you don't use proxy, then your IP will be logged.
- This command lists the log files:
http://victim.com/scripts/..%c0%af../.. %c 0%af../..%c0%af../..%c0%af../..%c0%af../. .%c0%af../..%c0%af../..%c0%af../winnt/sys tem32/cmd.exe?/c+dir+C:\Winnt\system32\Lo gfiles\W3SVC1
Capturing and maintaining log files are critical to the secure administration of a web server. While it is generally considered that the log does not capture an intrusion till after the request has been processed, a diligent administrator might couple logging with tools such as urlscan which will make logging more effective. Here, we will discuss some of the best practices that can be followed when it comes to IIS logs. The best way to emphasize the value and importance of IIS log files would be to draw a comparison to a crime scene, such that while handling IIS logs, they must be treated as if they are evidence already. Coupling IIS logs with other monitoring records such as Firewall logs, IDS logs, and even TCPDump can lend more credibility in the event of the log being used for evidence. |
The first rule is to configure the IIS logs to record every available field. Gathering information about Web visitors can help establish the source of an attack - either by linking it to a system or to a user. The more information that is collected, the better chance there is of pinning down the perpetrator.
The second rule is to capture events with a proper time stamp. This is because IIS records logs using UTC time. The accuracy of the UTC time can be ensured only if the local time zone setting is correct.
The third rule is to ensure continuity in the logs. IIS logs do not register a log entry if the server does not get any hits in a 24-hour period. This makes the presence of an empty log file ambiguous as there is no way of telling if the server received no hits, was offline or if the log file was actually deleted. The simplest workaround would be to use the Task Scheduler and schedule hits. In general, scheduled requests can indicate that the logging mechanism is functioning properly. Therefore, if a log file is missing, it is probably because the file was intentionally deleted.
The fourth rule is to ensure that logs are not modified in any way after they have been originally recorded. Once a log file is created, it is important to prevent the file from being accessed and audit any authorized and unauthorized access. One way to achieve this is to move the IIS logs off the Web server. File signatures are helpful because if a single file is corrupted, it does not invalidate the rest of the logs. Also, when doing any log file analysis, the original files must be never worked with. After the log is closed, no one should have permissions to modify the file contents.
Amarjit Singh
No comments:
Post a Comment