Web Server Security - About Unicode

About Unicode

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.
--------------------------------------------------------------------------------
[Example]

1) HackersCenter.com/~DoZ
2) This will turn "~" to "%7E" thus making this link HackersCenter.com/%7EDoZ/
--------------------------------------------------------------------------------
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 patched.

This exploit can be used when a writeable or executable directory is available, allowing Hackers to upload bad code.
Another is when a system executable such as cmd.exe is available on the root and does not have an access control list applied to it and
when an attacker sends a bad URL to a web server that looks something like this:

[protocol]://site/scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:

If the target has a virtual executable directory like 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 example, appending a/c as in the above example, indicates that it carries out the command specified by the sub ceding string and then stops. 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.

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 like .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 and excuted.

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.

[protocol]://site.com/../../../../../winnt/repair/file.

In this case, the web server will just look for the file in the web root directory called "../../../../../winnt/repair/file._". 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/file. _. The no. of '../"s does not matter as long as there are enough of them to change 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 bad 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.

Web Server Conclusion

Countermeasures for securing web servers include scanning for existing vulnerabilities and patching them immediately, anonymous access restriction, incoming traffic request screening and filtering. Also study the server and if possible get one and test it to its limits so you know its ins and outs.