Protect Exchange from buffer overflow attacks

Whenever you check for the latest security updates on Microsoft's website for Windows systems or most other Microsoft products, you will find that most important patches are designed to prevent Buffer Overflow. In such a design, an attacker can use a malicious code snippet as the basis for executing his/her own code.

There are many types of buffer overflow attacks, but they are all written based on malicious code or exploit the vulnerabilities in the original developed code programming language. Those programs written in C are the most vulnerable to buffer overflow attacks, because C Programs produce run time errors, in addition, most of the C databases used are not designed by default to perform error checks during execution, which is changing ).

If you can ensure that your input is correct, it is good to do not run the error check. However, hackers have discovered that when a user input of the C program is not checked for overflow, when the program fails to be executed, the program may enter a queue that contains a long Execution Code exception. This is why I tell you that most Windows operating systems and some Windows Server System products are written in C.

Do not look for my errors. Windows is not the only operating system that is vulnerable to cache overflow attacks of C Programs. It is also vulnerable to Linux attacks.

Two major cache overflow attacks are Stack attacks and heap attacks. Stack attacks are the most commonly used because they are the easiest to execute. A stack-based buffer operation is performed because the program uses a memory object as a stack to store user input. Generally, the stack is cleared before the program requests user input. At this point, the program writes a returned memory address to the stack, and users' input is placed at the top of the stack. When a stack is processed, user input is sent to the specified return address.

However, a stack does not have an unlimited size. The programmer code must specify the size of the pre-fabricated stack. If the user input is a metaphor for the predefined quantity, the stack will overflow. For the stack itself, overflow is not a major problem, but when malicious input occurs, it becomes a huge security vulnerability.

For example, a program wants the user to enter his/her name. Compared with the input name, hackers prefer to enter an executable command that exceeds the stack size. This command is usually very short. For example, commands in Linux usually require the system to open an instant command window, just like the Linux root kernel that everyone knows ).
However, the buffer overflow of an executable command does not mean that the command is to be executed. On the other hand, attackers must specify a return address to point to malicious commands. Therefore, part of the cause of program corruption is stack overflow. The program tries to fix the return address to be used, but the point of the return address is changed to the instruction specified by the hacker. This means that hackers must know where malicious commands will be stored. To know the exact address, malicious commands are often filled by the two parts indicated by NOP. If the specified address is filled, malicious commands are executed.

The last part is the executable program permission. As we all know, most popular operating systems have some mechanisms to control the user's logon access level. A typical requirement for executable programs is higher than that for normal login. Therefore, running in kernel mode or license permissions are inherited from the service account. When a stack overflow attack runs a command at a new return address, the program considers it to be running all the time. This means that the opened Command Prompt window is running the same batch of license commands as a security-threatening application. Generally, this means that attackers will gain all control over the operating system.

Protect yourself

So how can we protect you from such attacks? The easiest and most urgent technique is to ensure that your operating system, Exchange server, and other programs running on the server are updated in a timely manner. This will fix potential cache overflow usage.

Another trick is to exercise caution when using special applications running on it. I have seen many people use the domain administrator account as a service account. This problem occurs: if the service is not used properly, hackers will access your entire domain. It is best to run the service as a local system. However, if a service must use a user account as the service account, it is better to use a local user account than to use a domain account. On the other hand, if the service is compromised, attackers will be restricted to machines that control that server rather than the entire domain.

The last trick you can use is to use an application proxy. After an application proxy, the method is to stand between the user and the application and filter user input, determine whether user input is valid at the string layer and protocol layer. Unfortunately, you cannot store the Exchange Server on your computer and purchase an application proxy. However, when the configuration is correct, running Exchange in the frontend processing/backend processing configuration can achieve the same purpose as an application proxy.

Another example of an application proxy is a tool called URLscan. Although you cannot fully understand it, you can download this tool from Microsoft's Web site. This tool can monitor requests sent to your IIS server IIS as required by Exchange to ensure that the request is not too long and does not contain malicious code.