Description of errors, vulnerabilities, and exploits

Author: Mark Vogels
Translation: Ghost [S.S. T]

In this document, I will try to provide you with a basic understanding of errors, vulnerabilities caused by those errors, and their exploits. It never means that you can fully understand exploits and vulnerabilities, but it helps you learn about possible vulnerabilities and how to handle them.

Generally, three different types of errors may compromise the security of computer systems and networks.
# Programming error
# Configuration error
# Design error

Errors can be viewed as mistakes, although they are not all caused by accidents. The original creator of a software/device may have an error, but an error is created with the best idea, and is not aware that it may be a potential threat. This may sound a bit confusing, but it will be clarified later in the article. To explore more details about errors, we need to create a definition of different types of errors so that we can better understand them.

Definitions of different error types

Programming error:

Programming errors are usually caused by programmers. The most common programming error is buffer overflow. Imagine a buffer overflow as an empty cup: the user of the program will pour coffee into the cup, but the programmer does not know how much coffee the user will pour in beforehand. Therefore, the programmer must check and test the coffee before it is poured into the cup to prevent the coffee from overflowing. Sometimes it is not easy to check the input size, or the programmer does not have time to write a wide range of error detection functions due to time constraints. The result is: Possible Buffer Overflow and other programming errors are created.

Another example of programming errors is that when users do unexpected things, such as loading an error-type file to a program, the program will crash. Of course, not all programming errors require user input for unexpected tasks, such as program crash. A program also depends on a special file that is always in a specific location. If the file is moved and the programmer does not expect it, it is impossible for the programmer to detect whether the file is still in that location before the program tries to open it. If the program tries to run the file after opening it, this will lead to unpredictable behavior.

These types of errors occur quite frequently, and most of the time the vendor distributes patch packages to solve the reported errors found by consumers or themselves.

Configuration error:

Imagine a configuration error: if you are a network administrator and you need to run a firewall to protect your network. In practice, you will allow any incoming and outgoing traffic, except for the type of traffic specifically rejected.

A simple example is that the firewall only blocks port 80, but it will allow anyone from the Internet to connect to the firewall's configuration page to reconfigure it. All other ports are open. This is obviously a configuration error. Anyone can bypass the firewall by using another port number.

Fortunately, most vendors know this error, so they do the opposite: any traffic is blocked unless specifically permitted. Therefore, since the port is disabled, the network administrator no longer needs to worry about new problems, and can access the network through an unused port. (Here I only use ports for example, but different types of traffic can be applied on the same port .)

Another example of misconfiguration is the use of an unmanaged hub in a network instead of a manageable switch. The difference is that the hub sends all incoming data packets to all ports because it does not know which port the receiver is located next to it, and the switch knows. Therefore, to run a sniffer in a network using a hub instead of a vswitch, an attacker is allowed to view more data packets containing the possible usernames and passwords. The solution is to use a vswitch in the network. Even if this is a configuration error, it is not in the past, because the switch does not exist at that time.
　　
Design error:

Design errors can be seen as errors in the software design phase. Even if the programmer spends enough time writing a detection process before the software is released to test the input of all users, even if the software is correctly configured by the end user, these errors still pose a great risk to the security of a network.

Let's look at this situation: a company decides to develop a software that allows remote access to a network. They also had to support the software, so they decided to put some backdoors in it so that they could use the company name as the password for remote login. What happens if people outside of the company discover those backdoors? He can use the software for remote access to log on to any network. The results will be disastrous!

Although these backdoors were created quite frequently in the past, a company now sells similar software without causing any further risks because it is responsible for the abuse of backdoors by attackers.

Another example of a design error is the use of WEP encryption in a secure wireless network. I am not going to explain in depth why this is a design error. After all, it is beyond the scope of this article, but its basic process is as follows:
A 3-byte initialization vector is added to the public key to encrypt each unique packet. Assume that the public key is abcde. The initialization vector of the first packet is 123, so all the keys of this packet are 123 abcde. The initialization vector of the next packet is 234, and its key is 234 abcde.

The design error here is actually that only three bytes of different Initialization vectors lead to 255 ^ 3 or 16.5 million different keys and some encryption algorithms being used. Through some reverse analysis algorithms, several characters in the public key can be easily obtained. Due to this design error, you only need to use the unique initialization vector to repeatedly send 0.1 million packets (64-bit), send 0.8 million packets (128-bit ), you can break through the WEP-key and enter the complete wireless network. In a busy wireless network, this can be done within a few hours.

As you can see, the design error is a bit more difficult to solve. You cannot solve this problem simply by expecting the vendor to release a quick update, or by referring to the product manual. In the case of WEP encryption, a group created a new standard called WPA. This means that WEP-encrypted products should be replaced, or hardware updates should be used to allow them to work with this new encryption standard. For detailed descriptions of the design errors on the WEP that have been found, you can go to airbench. Com.

How do these errors become vulnerabilities?

A vulnerability is a weakness in the Protection of targets. The target can be any part of a computer connected to a complete network. I won't explain all the differences between the possible vulnerabilities here, because they are almost impossible, but I will try to point out what the vulnerabilities are and how they are generated.

According to earlier regulations, the most common programming error of a vulnerability is buffer overflow. Assume that a stack-based buffer overflow occurs, and the buffer is placed in the stack. Stack can be seen as a temporary workspace where your processor stores data and can work with it. Now, when you overflow a buffer in the stack, you can write data out of the buffer in the allocated space, so you can write other data into the stack. Other data can be the return address of the call function. Assume that the return address of the function to be called is 12345678, And the return address is directly stored in the stack behind the buffer, the stack may look like this:
XXXXXXXXXX12345678

XXXXXXXXXX is the buffer that will contain our input. If we put some data that is smaller than the buffer size, nothing strange will happen, but when we put 12 'A' in A buffer that can only bear 10 characters, the extra two a' will overwrite the return address. So that the return address becomes an invalid address, and the function cannot return, the program crashes.

If this program is A server application, someone can put 12 A to crash the program and make it inaccessible to all other users. This is an example of a Denial-of-Service attack. In this case, a denial of service vulnerability exists.

If we use the same example as above, but change to a larger buffer zone, the overflow buffer means that more data must be put before an actual overflow occurs, but when that happens, we can write some computer code (assembly instructions) and use it as part of the data in the buffer zone. We overwrite it to change the return address to point to the end of our overflow buffer, and the program will try to execute our buffer. At this time, the buffer contains the code we put in, and the program will not crash, but instead go to execute our code. Because the code can be a small segment of code that enables a shell (command interpreter) and listens to a special port on that computer, this type of code is often called shellcode.

With the code running, someone can connect to the special port and execute remote commands, at the same time, it obtains control of the same access rights as the user who opens the vulnerability application on the remote computer.

For configuration errors, if we look at the firewall example, the vulnerability becomes more obvious. If the firewall can be remotely configured via telnet, only port 80 that does not allow access to the firewall will give the network administrator a security error, attackers can still configure access through port 23 connected to the firewall.

However, since consumers began to require that the products they purchased should have different configuration options, manufacturers began to develop high-level software and equipment that can be configured. This may make the configuration of a device professional and cause errors easily. The configuration of similar devices is so complex that the vulnerability can be seen by network administrators. Therefore, a potential attacker is allowed to access the network or the part that the system should not have accessed, therefore, a simple configuration error may cause a potential vulnerability in the network and system.

I have provided an example of a vulnerability caused by a design error: WEP key, but it can easily lead to another example of a design error: imagine a software company preparing a software for browsing and creating text documents. They want to sell their products, but since competitor software companies have also developed software with the same functionality, they have to design a program with more powerful functionality on the surface. Therefore, they decided to add a feature that allows users to have more control over their own documents, so that users can write small functions (macros) and be embedded in the document, at the same time, it can help document viewers do all kinds of things on their computers. If all these functions are used by a malicious attacker, create a macro-embedded document that can copy itself to all other documents found on the machine, and do all kinds of other things without the consent of the viewer? We have another possible vulnerability in this designed and created program.

As you can see, an error may cause a vulnerability. The idea of helping software users create more dynamic documents is great when macros are used in the document, except when security considerations are not taken into account.

So what is an exploit?

Exploit is a method that uses a detected vulnerability to change the initial functions of a program or system. This method is more useful for an attacker. In computer security, the term "exploit" is often used to describe a special program. Its sole purpose is to automatically exploit a vulnerability to gain control over the target program with the vulnerability, or terminate the normal functions of the target program.

However, using an incorrect configuration in a system or network can also be called an exploit for attackers who want to use it, although it is not necessarily a special program that can actually complete the work.

I will use some C code examples to illustrate the role of an exploit. One of them is a simple program with a buffer overflow vulnerability, and the other is exploit.

Note: The example given here may be different in different compilers and systems. You may need to change the number of characters in the buffer to actually rewrite the return address, or the exploitfunction address may be different, but they can still work.

Vulnerable_program.c:

Copy code
# Include "stdio. H"
/* Use the function */
Exploitfunction ()
{
/* If the buffer overflow is used successfully, the content of this row will be output */
Printf ("This line will be printed after successfully exploiting the buffer overflow .");
System ("pause ");
ExitProcess (0 );
}

Normalfunction (char * myargument)
{
Char buffer [10];
Strcpy (buffer, myargument );
}

Main (int argc, char * argv [])
{
If (argc> 1)
{
Normalfunction (argv [1]);
Printf ("These lines get printed during normal execution with at least 1 commandline argument. The address of exploitfunction
Is 0x %. 8X ", & exploitfunction );
}
Else
Printf ("Please provide the program with at least 1 commandline argument .");
ExitProcess (0 );
}

I have created three functions, one of which is the main function and the other two, namely, the normalfunction executed under normal circumstances and the exploitfunction. The purpose of the program is to overflow the buffer so that the return address will point to the exploitfunction that replaces the next instruction after normalfunction.

Now we need to specify the size of the text string to completely overwrite the return address in the stack. It's easy to achieve this goal! We add one character each time until the program crashes.

After I use Dev-cpp on Windows to compile the program, I know that A maximum of 27 A s are required before the program crashes.
The address of the exploitfunction is represented in hexadecimal notation, And the byte value often shows that the address is a non-printable character. I wrote a small program that will provide the necessary strings for this vulnerable program to use.

In my environment, the exploitfunction address (which is easily printed inside the vulnerable program) is 0x00401290. Because the stack stores all data in reverse order on Intel x86 systems (not described in this document), we need to prepare the same string. Therefore, the possible values are similar
0x41414141414141414141414141414141414141414141414141414141901240.

As you can see, here the character 'a' (0x41) is represented in hexadecimal notation, which is the real value stored in the stack. The result is that exploit is very simple:

Exploit. c:

Copy code
# Include "stdio. h"
Main ()
{
Char workbuffer [200];
Char tempbuf [4];
Strcpy (workbuffer, "vulnerable_program aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ");
Tempbuf [0] = 0x90;
Tempbuf [1] = 0x12;
Tempbuf [2] = 0x40;
Tempbuf [3] = 0;
Strcat (workbuffer, tempbuf );
System (workbuffer );
Return 0;
}

What this program does is to copy the string "vulnerable_program aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" to a buffer zone, create another buffer zone with a new return address, and attach it to the working buffer zone.
After that, the program calls system () to execute the command in the string. The output result is:
C:> exploit.exe
This line will be printed after successfully exploiting the buffer overflow.
Press any key to continue ......

Great. It's executed!

Isn't that great?

Although we have not actually succeeded in letting the program run our own code, it can be done through some small changes.
For more information about buffer overflow, see the famous article "Smashing the stack for fun and profit" written by Aleph One"

After discussion in this article, you usually have to take actions to prevent your system or network from being exploited by a known vulnerability. For configuration errors, I suggest you ask an expert to help you with the necessary configurations. Therefore, you do not have to fully understand how the product works before using it. For programming and design errors, many people usually perform product tests, while others publish the vulnerabilities they have discovered to some security lists on the Internet. So if you keep following these security lists and make sure that you have been updating your system to the latest version, you are close to a secure environment.

―――――――――――――――――――――――――――――――――――――――― ――
Recent security programming documents:

Exploiting Software How to Break Code
Describes how to compile the exploit code

Learning XML, 2nd Edition

Writing Secure Code
The core recommendation of Microsoft is to teach you how to write secure code.

OReilly Web Site Cookbook
Create and manage user manuals for your website, including a large number of instances and Solutions