Protect Exchange from buffer overrun attacks

Stack and heap attacks are the two main types of buffer overrun attacks. How can you protect your Exchange server from them? This tip gives some revengeful advice.

On any given day, if you were to check the Microsoft web site for the latest security updates for Windows (or for

most other Microsoft products), you will find that the majority of the patches available are designed to patch areas of the system that are susceptible to buffer overrun exploits.

The main idea behind such an exploit is that an attacker can use a poorly constructed piece of code as a base for executing his/her own code. Unfortunately, there are a lot of myths going around about buffer overrun attacks.

There are an infinite variety of buffer overrun attack types, but they all stem from either poorly written code or from weaknesses in the programming language that was used to develop the code. Programs that are written in C are notoriously susceptible to buffer overrun attacks because of the way that C programs produce run time errors and because of the fact that many of the most commonly used C libraries are not designed to do any sort of error checking by default in the interest of performance (this is starting to change).

Not performing error checking on input is fine if you can guarantee that the input will be valid, but hackers have found that when a C program with unchecked buffers asks for user input, it is possible to enter an excessively long string containing executable code, in an effort to crash the program and execute the code. The reason why I am telling you this is because much of the Windows operating system and many of the Windows Server products are written in C.

Don't get me wrong, though. Windows is not the only operating system that is susceptible to a buffer overrun attack. C programs running in Linux are also susceptible.

Stack attacks are most common
The two main types of buffer overrun attacks are stack attacks and heap attacks. Stack attacks are by far the most common because they are the easiest to perform. The reason why a stack-based buffer run works is because the program being exploited uses a memory object known as a stack to store user input. Normally, the stack will be empty until the program requires user input. At that point, the program writes a return memory address to the stack and then the user's input is placed on top of it. When the stack is processed, the user's input gets sent to the return address specified by the program.

A stack does not have an infinite potential size, though. The programmer who develops the code must reserve a specific amount of space for the stack. If the user's input is longer than the amount of space reserved for it within the stack, then the stack will overflow. This in itself isn't a huge problem, but becomes a huge security hole when combined with malicious input.

Suppose, for example, that a program is expecting a user to enter his/her name. Rather than entering the name, the hacker would enter an executable command that exceeds the stack size. The command is usually something short. For example, in a Linux environment the command is typically EXEC("sh") which tells the system to open a command prompt window (known as a root shell in Linux circles).

Overflowing the buffer with an executable command doesn't mean that the command will be executed, however. The other part of the process is that the attacker must specify a return address that points to the malicious command. Therefore, the program partially crashes because the stack overflowed. The program tries to recover by going to the return address, but the return address has been changed to point to the command specified by the hacker. This means that the hacker must know the address that the malicious command will reside at. To keep from having to know the exact address, though, the malicious command is often padded on both sides by NOP instructions. The malicious command will be executed if the address that the hacker specifies falls anywhere within the padding.

The last part of the equation is the executable program's permissions. As you know, most modern operating systems have some sort of mechanism to control the access level of the user that's currently logged on. Executable programs typically require a higher level of permissions than the currently logged on user and are therefore run either in kernel mode or with permissions inherited from a service account. When a stack overflow attack runs the command found at the new return address, the program thinks that it is still running. This means that the command prompt window that has been opened is running with the same set of permissions as the application that was compromised. Generally speaking, this often means that the attacker will gain full control of the operating system.

Techniques to protect yourself
So how can you protect yourself from this sort of attack? The easiest and most critical technique is to keep Windows, Exchange and anything else running on the server up to date. This will repair must potential buffer overrun exploits as they are discovered.

Another technique that you can use is to be careful about what privileges applications are running with. I have seen a lot of people use the domain administrator's account as a service account. The problem with doing so is that if the service is exploited then the hacker will have access to the entire domain. It's best to run services as LocalSystem. If a service absolutely requires using a user account as a service account, though, use a local user account rather than a domain account. That way, if the service is compromised then the attacker will be limited to controlling that one server rather than the entire domain.

One final technique that you can employ is to use an application proxy. The idea behind an application proxy is that it stands between the user and the application and filter user's input, both at the string level and at the protocol level, to make sure that the input is valid. Unfortunately, you can't just go to the computer store and buy an application proxy for Exchange Server. However, running Exchange in a front end/backend configuration can serve the same purpose as an application proxy when properly configured.

Although not comprehensive, another example of an application proxy is a tool that you can download from the Microsoft Web site called URLscan. This tool monitors requests coming into your IIS Server (IIS is required by Exchange) to make sure that requests are not excessively long and do not contain malicious code.

Using URLscan is a great way of protecting your OWA front-end server against buffer overrun and other types of attacks generated by entering malicious URL stings.


Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.


Do you have a useful Exchange tip to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.
This was first published in September 2004

Dig deeper on Spam and virus protection

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close