Oday or exp Mining Techniques

Many times we have a strong passion for all kinds of 0-day or exp. Indeed, holding this powerful weapon of destruction will make the fight against the target very smooth, however, the problem is that not everyone can grasp the latest 0day in time, and it should be clear that there are still a lot of 0days that we don't know, which are usually sold at high prices. Just like a heavy weapon, not everyone can own it. If you want it, you have to pay for it-if you cannot create it yourself. Based on the above, why don't we dig something ourselves?
 
 
In fact, this article does not describe the various mining techniques of 0-day in detail, because to write in detail all aspects is enough to write a book, and I am just a rookie who can't write so many things, here we will talk about some of my personal experiences and understandings.
 
There are two types of scenarios: open-source and non-open-source programs. In fact, the use of open source is not accurate, the reason is very simple: many commercial web programs can directly view the source code even if their program files, however, it is not easy for you to obtain it unless you just intrude into a website using the program and pack the code back. Well, let's understand: the open source here can be understood as-you can directly view the source code. We believe that all program bugs are code errors. Both Red bugs and security bugs are problematic in code writing. Therefore, if you can get the source code of the target, it will become easier to some extent. In this case, it is called white box testing. Although some black boxes may not be able to find problems (in fact, many automated vulnerability scanning tools will omit many actual vulnerabilities in the scan results) but it is not equal to that the white box can completely replace the black box. The reason is simple: although computers cannot completely replace the human brain, it can save a lot of resources to hand over large-scale repetitive jobs to machine processing. The value of the white box lies in discovering hidden deep vulnerabilities that the black box cannot discover, such as the DZ7.2 event. However, white boxes are a little useless for obvious problems, such:
 
Dim rs, SQL, id
 
Id = request ("id ")
 
Set rs = server. creatobject ("adodb. recordset ")
 
SQL = "select * from user where id =" & id
 
Rs. open SQL, conn, 1, 3
 
>
As I have said before, I will not elaborate on how to mine vulnerabilities here. In fact, mining web script vulnerabilities will naturally become handy as long as you are familiar with the concepts and causes of various vulnerabilities. For example, SQL inj. the reason is that the dynamic interaction variables are not well filtered or purified, so that malicious users can submit carefully constructed SQL query statements to obtain expected data or information. After understanding this section, you can easily understand the SQL inj. Vulnerability in the above Code. Although www.2cto.com is the simplest case, it remains unchanged.
The Source Code cannot be obtained. A typical example is a compiled binary file. For these programs, fuzz test is usually used. (However, source code can also be decompiled for. net and java ). Bill Gates once said that input by any user is harmful. In fact, what malicious users can control is where they can submit data. Of course, we can systematize the idea: first, there must be something wrong with the Code. Second, the program is certainly designed to provide a function that meets one or more of the user's needs. Finally, since there is a problem with the code, in terms of the operation of these functions, there must be one or more attacks. Well, let's visualize the following: for example, in the FTP program, the first question must be the file transfer, but if anonymous access is not allowed (in many cases, this is the case), the user must submit the authentication, that is, the most basic user name and password. Well, the user can control the place where the user appears-the submitted user name and password. These are variables and user controllable variables, what if the program is dealing with these variables? For example, if we enter a too long user name or password, will it cause stack overflow or the like? For another example, the browser program returns a standard html document to the user. Let's assume that if the browser does not properly handle a combination of one or more html tags? The most likely cause is a DOS program crash. Of course, there may be more and more problems with browsers. Cross-Domain issues will be a hot topic in the web era-I think so. To sum up, it is a feasible idea to fully understand the functions of the Target Program, and then consider the possible problems in processing various functions-and then conduct targeted tests.