SQL alternative injection bypass background login verification

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. I mentioned that the website's background management system is directly accessible without background login verification. I think everyone can think of the classic universal password: or = or. Today I want to share with you a similar skill, however, 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") 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 & "And PassWord =" & encrypt (pwd) & "" 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:
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
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 in the username, so that the SQL statement becomes: select * from Manage_User where UserName = 'or' = or And PassWord = 123456. 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 & "" Put 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 it. Some may have doubts here. If we submit or = or, then the SQL statement becomes: select * from Manage_User where UserName = or, the result should also be true. Why can't we bypass it?

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.

Well, for the analysis of the or = or vulnerability, let's talk about it for the moment. The above are my personal understandings of the vulnerability, and it does not mean it is completely correct, if anything is inappropriate, I hope you will give us more advice. Next we will be playing a major role.

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 of little use 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
If trim (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)
Set rsLogin = 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:

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 equals the user's input user name from the Administrator table. If the query finds that a certain record exists in the management table, 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 the current