Ecreate network SQL Injection

I was interested in code auditing recently. Therefore, I wrote a process to check the code and find the vulnerability.

I am also a beginner in code auditing. I am not getting started yet. I just want to find the following vulnerabilities:

1. execute commands such as php system functions
2. Execute functions such as eval in code.
3. The object operation is to obtain webshell
Upload, file modification, File Read (download), and file list. You should check all file-related information.
4. Excessive permission judgment is often harmful.
Horizontal and vertical permission escalation, cookie spoofing bypass verification.
5. Search by SQL command keyword in SQL Injection
In this way, you can determine all the variables that enter the SQL statement (directly input or multi-level injection)
6. xss is basically out of scope. I won't use it...

7. Difficult to find logical Vulnerabilities

8. Other problems
Brute force cracking
Destructive attacks may cause serious risks when the machine is on its own.
Configuration problems
Error message Unblocked

Because you can only understand some asp code, find an asp program)

Official Website: http://www.echsys.com/
Source Code address: http://www.echsys.com/EC0703.V6014.rar

After studying for a few days, I found that the current source code audit is a dangerous function search. It seems that I have not seen any dynamically executed source code audit tool. If it is a search function
That is to search for strings in the file. I will use the notepad ++ tool, but after a while, I will find that it is not satisfactory. notepad ++
It seems that you can only search for one character string and cannot search in batches. This is a bit troublesome and a bit blind. After sitting in front of the computer and thinking for a long time, I think I should write it myself.
Search for strings. You can search for all matching strings in a folder Based on the specified string (Regular Expression) list.

Therefore, we must first have a list, but how can we create a list? Let's take a look at the cause of the vulnerability...
1. user input is what can cause the Vulnerability (all input is harmful ).
2. Key operations corresponding to key functions (all input to the function is harmful, multi-level input)

Based on the above two points, I thought about a list for a long time:
Request # input
Server. createobject # object
Multipart/form-data # file upload
Execute # code execute
Eval # code execute
Select # SQL
Insert # SQL
Update # SQL
Delete # SQL

Now I want to think about this. I will try again later. It is easy to understand here. I use # As a separator. The variable to be matched is in the front, which is explained later.

With the list, you need a tool that matches the list. It seems that someone has written it, but I still want to write it myself. It should be later.
Easy. Also exercise a bit of code writing to find a better job in the future...

Use c # To write a rough interface:
Basic functions:
1. Read the list to be matched from the file
2. You can select a folder, traverse all files, perform matching, and pick out all satisfied results.

3. You can specify the matching file suffix. For example, I don't need to match the php Suffix in asp cms, and many image files do not need to match.
4. You can only search for one keyword (there are two modes, one is matching, and the other is not matching). When we only need one file for permission
During the check, if a file in a folder does not contain the file, it is unauthorized access, which is actually very good. At least I do.
Yes.

Basically, I thought of this and started... after a few days, I could use it after repair, modification, and modification. There are still 108,000 miles away from the beauty...

Test the download source code and the string list above:


Obtain the following results. Then I started to read .... The Code Execution contains the eval tragedy of js (which can only be ignored). However, no server handles the file. Let's take a look at input.


Select notepad ++ to enable it (because I didn't write out the highlight function of the selection)


I found that there are a lot of include in it. Let's take a closer look at it and verify whether the user is logged on. Chkuser. asp source code is as follows:


Obtain the user name and password in the cookie: the user name is processed using checkstr, and the single quotation marks are escaped. although the password is not processed, the query statement is not entered, so it cannot be injected or bypassed.
That is to say, its permission judgment is okay. At least I haven't bypassed it yet, huh, huh.

If you have the permission to bypass the background function, it is critical for me to get the background function from the foreground. Therefore, we should first check whether there are any vulnerabilities on those pages that do not have the permission check. That is, the code that does not contain include file = "chkuser. asp.
I. cookie Injection
Therefore, reconfiguration:


Find all. asp files that do not contain checkuser. asp. Query all front-end pages. Soon the results came out:


When I started viewing the file, I found the tragedy only when I opened the file. I downloaded the test version, and there was no content on many pages. The tragedy was terrible, but I couldn't give up. Check it in the search list.


When you access ChkManageLogin. asp, use notepad ++ to open it.
<! -- # Include file = "conn. asp" -->
<! -- # Include file = "char. inc" -->
<! -- # Include file = "config. asp" -->
<! -- # Include file = "md5.asp" -->

<%
'On error resume next
Dim rs
UserName1 = CheckStr (request. form ("UserName") // obtain the user name
Passwd1 = md5 (trim (request. form ("passwd") // md5 password
Verifycode = cstr (trim (request. form ("verifycode") // Verification Code
Dim ViewUrl1
ViewUrl1 = "admin_index.asp"


If cstr (session ("verifycode") <> verifycode then
Show_Err ("Verification code error. It may be that you have stayed on the Management logon page for too long. Please go back and refresh the page. <Br> <a href = 'javascript: history. back () '> return </a> ")
Response. end
Else
Set rs = server. createobject ("adodb. recordset ")
SQL = "select * from" & db_EC_Manage_Table & "where (" & db_ManageUser_Name & "= '" & username1 & "' and adder = '" & Request. cookie (eChsys) ("username") & "')" // an obvious cookie injection point
Rs. open SQL, Conn, 1, 3
If (passwd1 <> rs (db_ManageUser_Password) or UserName1 <> rs (db_ManageUser_Name) then
Show_Err ("An error occurred while using the user name or password. Please return and check <br> <a href = 'javascript: history. back () '> return again </a> ")
Response. end
Else
Rs (db_ManageUser_LastLoginIP) = Request. ServerVariables ("REMOTE_ADDR ")
Rs (db_ManageUser_LastLoginTime) = Now ()
Rs (db_ManageUser_LoginTimes) = rs (db_ManageUser_LoginTimes) + 1
Rs. update

From the code above, it is easy to see that the Request. cookies (eChsys) ("username") are not filtered to cause cookie injection. However, the preceding verification code must be verified by the Verification code. If you use session to save the verification code, and the verification code is not updated when the verification error occurs, it means that as long as the verification code is caught on the web page, if cookieid is included in the next access, the verification code in the session is correct and can be verified. The verification code problem is solved.

If the verification succeeds, you can directly jump to admin_index.asp, but the page is encrypted. This is really not a good deal. We have to build a decryption tool. The decryption is as follows:


No, it is more direct. cookie injection is too obvious and there is no verification code restriction. If SQL Execution fails, it will jump to login. asp page. If the execution is successful, the page will not jump. You can do this to determine whether the SQL Execution is successful. A blind injection point. The administrator user name and password can be obtained from any of the above two injection points. Another problem is the cookie prefix. When login. asp is accessed, the cookie prefix is leaked:
Everything is ready. It is a tool to guess the user and password. I think it's really troublesome to guess completely. Continue to check the code and find that there is another page like this.
E_alluser.asp will display all registered members. If you know the user name, you only need to guess the corresponding password. Because the table structure and so on are known, it is easy to write a program that guesses the password as follows:

 



Ii. cookie spoofing bypass authentication
However, the passwords are all md5 encrypted. If the password cannot be cracked, it is not a tragedy. So let's take a look at the verification method of the program. Two levels of verification, two verification files. The Chkuser. asp and ChkManage. asp codes are similar, except that the table names are different. One is a common user and the other is user verification management.
UserName = CheckStr (trim (Request. cookies (eChsys) ("UserName ")))
M_UserName = CheckStr (trim (Request. cookies (eChsys) ("ManageUserName ")))
M_PassWD = trim (Request. cookies (eChsys) ("ManagePasswd "))
M_Key = trim (request. cookies (eChsys) ("ManageKEY "))
Set urs = server. createobject ("adodb. recordset ")
SQL = "select * from" & db_EC_Manage_Table & "where (" & db_ManageUser_Name & "= '" & M_UserName & "' and adder = '" & UserName &"')"
Urs. open SQL, Conn, 1, 3
If urs. bof or urs. eof then
If IsDebug = "1" then
Show_Err ("using cookies (username) and cookies (ManageUserName) return values, the corresponding records in the Management User table cannot be found. <Br> <a href = 'javascript: history. back () '> return </a> ")
Else
Response. redirect "admin_index.asp? Action = Manage. asp"
End if
Response. end
Else
If M_PassWD <> urs (db_ManageUser_Password) then
If IsDebug = "1" then
The return value of Show_Err ("cookies (ManagePasswd) does not match the Password value recorded in the Management User table. <Br> <a href = 'javascript: history. back () '> return </a> ")
Else
Response. redirect "admin_index.asp? Action = Manage. asp"
End if
Response. end
Else

It can be seen that it is actually getting the value, user name and password from the cookie, and the user name cannot be injected due to the processing of the user name, and the corresponding password is obtained according to the user name query. The password is md5 encrypted, if the password is the same as the one in the submitted cookie, the verification is passed. This means that you don't have to crack md5 at all. It's great to save a dime.

3. Obtain shell through file operations
Entering the background is often not the ultimate goal. It is generally used to obtain a webshell. Therefore, our goal is to find a place with file operations.
There are several categories: File Upload, file modification, and file backup. Everyone understands this and won't write more here. It's easy to get the shell to use the db_compact.asp file in the background. (A little long, afraid that the dark clouds will not let go)
Solution:It is easy to fix. The main problem is cookie injection. Therefore, as long as the programmer calls the security function after obtaining the cookie.